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
