I re-opened SOLR-15223 to highlight that we are still blocked by this decision.
I don't clearly see the full effects of your suggestion right now. Does your proposal also involve deprecating CloudHttp2SolrClient as a separate class? I would imagine users with existing SolrJ code would after upgrading get an instance of BaseCloudSolrClient (with a new name) using Jetty client under the hood? What if that application code assumes org.apache.http as client and tries to obtain HttpSolrClient and even org.apache.http objects based on CloudSolrClient? The code would fail since the contract is broken. With the current pure deprecation and switch to CloudHttp2SolrClient, existing users' code would continue to work.. Jan > 14. mar. 2022 kl. 15:40 skrev David Smiley <dsmi...@apache.org>: > > 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 > <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 > <http://www.linkedin.com/in/davidwsmiley>
