I want to bring an important SolrJ decision to the dev list. There's a JIRA issue https://issues.apache.org/jira/browse/SOLR-15223 "Deprecate HttpSolrClient and friends in 9.0"
Sounds great by the title -- we want to transition over time to the Jetty client instead. Jan submitted a PR to deprecate CloudSolrClient and some others, and I approved it because these classes intimately assume the Apache HttpClient. It's merged. But I have serious doubts now and wish to discuss it with the dev list. Copying my last message on the issue: Now that I'm "seeing" the results of this in my IDE, seeing the > cross-through of deprecated usage on innocent looking classes like > CloudSolrClient in particular, I have doubts on the approach. > "CloudSolrClient" is an intuitive/obvious name to a user that wants to talk > to SolrCloud. The particulars of which HTTP protocol or wether the client > is using whatever HTTP library is all an implementation detail. Ideally > such decisions would be done in the builder, either a common builder or if > not then a builder specific to those libraries if needed (less nice but > acceptable IMO). > > The easiest way to get there is to rename CloudSolrClient to > CloudHttp1SolrClient in one commit (merge it) and then rename > BaseCloudSolrClient to simply CloudSolrClient in the next. Then add a > Builder to this class that is the one in Http2; subclass it or something > (details TBD). > > WDYT? > > Of course, today they are separated by their classes. Maybe we should > simply convey the deprecation intent in the upgrade notes as an advanced > warning, but not deprecate CloudSolrClient in particular. > Jan replied: Since we did not deprecate these in 8.x, we still have a back-compat > promise to keep these classes around in 9.x, and thus also the old http > client. But perhaps we are breaking that promise already in SOLR-16061 > <https://issues.apache.org/jira/browse/SOLR-16061>, so maybe we can > change even more > > I don't like the CloudHttp2SolrClient naming either, would prefer the Http > client to be abstracted away so that it could be swapped out as an impl > detail, but it was not designed that way. I fear that re-using the same > class name but with slightly different contract is harder to explain than a > clear deprecation message in the IDE pointing you to the replacement. > > Perhaps the one client to rule them all in 10.0 should be > ClusterSolrClient? And aim for it to be constructed with either a Jetty > client or JDK8-HttpClient as backbone through different factories/builder? > How is the contract between CloudSolrClient & BaseCloudSolrClient different Jan? I suspect if there's breakage, it'd be relatively obscure options on the builder. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley
