You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "David Smiley (Jira)" <ji...@apache.org> on 2022/03/13 13:36:00 UTC
[jira] [Commented] (SOLR-15223) Deprecate HttpSolrClient and friends in 9.0
[ https://issues.apache.org/jira/browse/SOLR-15223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17505449#comment-17505449 ]
David Smiley commented on SOLR-15223:
-------------------------------------
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 a 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.
> Deprecate HttpSolrClient and friends in 9.0
> -------------------------------------------
>
> Key: SOLR-15223
> URL: https://issues.apache.org/jira/browse/SOLR-15223
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Reporter: David Smiley
> Assignee: Jan Høydahl
> Priority: Major
> Labels: newdev
> Fix For: 9.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Solr has had an HTTP/2 based SolrClient since 8.0. Maintaining both HTTP/1 and HTTP/2 clients is a pain for maintenance of the project as it sometimes means duplicative (or partially implemented) work, especially for authentication but also sometimes metrics or tracing. Both adds extra dependencies for SolrJ and thus our users. It's difficult to grok a codebase using two different HTTP client frameworks.
> In this issue, mark HttpSolrClient (and related ones) as deprecated; point to HTTP/2 equivalents. ~Furthermore, mark the Apache "httpcomponents" libs as "optional" in the produced Maven pom.xml so that users have to explicitly opt-in to use it. Announce this in the Solr users list as well.~
> Out of scope to this issue is completely cutting over within Solr itself.
> The plan is to remove apache http client in main branch (10.0)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org