I agree we shouldn't need the apache client when jetty is used. But making Apache and Jetty implementations of the APIs is a big ask, and I'm not sure it's worth the maintenance effort.
- Houston On Tue, Mar 28, 2023 at 3:32 PM Kevin Risden <kris...@apache.org> wrote: > 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 > > > > >
