[ 
https://issues.apache.org/jira/browse/SOLR-15223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17506071#comment-17506071
 ] 

Jan Høydahl commented on SOLR-15223:
------------------------------------

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, 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?

> 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-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Reply via email to