Thanks for surfacing this here. I wouldn't have noticed had you not brought it up here. This deserves broad agreement, if not a SIP styled discussion/voting. I'll go through the proposal and review soon. Thanks David & Jan!
On Mon, 14 Mar, 2022, 8:11 pm David Smiley, <dsmi...@apache.org> wrote: > 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 >
