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
