This was introduced here - https://github.com/apache/solr/commit/8efed0555898f485d435d53a72cb6441507d81e1#diff-db379c74efc9ff28acfd7571b07e16dbcdaa510783f2bee835b4a288927b5b3d
It looks like it inadvertently copied from HttpSolrClient.java and used ContentType.parse(ct).getMimeType() instead of MimeTypes.getContentTypeWithoutCharset(ct) Kevin Risden On Tue, Mar 28, 2023 at 1:49 AM Jan Høydahl <jan....@cominvent.com> wrote: > Good find! I’d say create a jira on making solrj client side work with > apache client excluded. Makes sense. > > Jan Høydahl > > > 28. mar. 2023 kl. 07:04 skrev Shawn Heisey <apa...@elyograg.org>: > > > > I have some simple solrj code pulling in solrj 9.2.0 that creates a > client (Http2SolrClient) and then uses that to send a collection creation > request. I know, I should probably use a Cloud client, but I'm emulating a > customer setup where they are on SolrJ 4.7.0 and using HttpSolrServer. > > > > In order to trim down the ultimate size of my sandbox app, I theorized > that Http2SolrClient was not using the Apache httpclient, so I excluded all > the org.apache.httpcomponents artifacts. > > > > My simple code failed, because Http2SolrClient is using > org.apache.http.entity.ContentType from the Apache client. > > > > The usage can be found in branch_9_2 Http2SolrClient.java on line 823. > > > > I couldn't figure out a way to do that with the Jetty client, but I > admit I didn't try much beyond seeing if there was an alternate version of > the ContentType class. The usage is in a lambda, and I don't understand > lambdas very well. > > > > How much of a mess is it going to be to remove that last Apache > httpclient usage? > > > > There are a lot of other usages from httpcomponents across the main Solr > codebase. I think it might be a worthwhile project to convert those, to > use classes included with Java whenever possible, and resort to Jetty or > another already-present dependency where absolutely required. > > > > I wonder if it might be worthwhile to create an abstract class in Solr > for http clients, and have descendants of that class which implement > functionality using jetty and apache clients. If that is pursued, that > work should probably be limited to main until it is stable. If we do that > and do it right, then we would be free to swap out the http client > implementation at any time, if we find something that works better than > either Jetty or Apache. > > > > Thanks, > > Shawn > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
