[
https://issues.apache.org/jira/browse/SOLR-16368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17616706#comment-17616706
]
ASF subversion and git services commented on SOLR-16368:
--------------------------------------------------------
Commit 02a1ff4b41d4d7abd0c017adc8d49f1a61e1e45b in solr's branch
refs/heads/main from Eric Pugh
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=02a1ff4b41d ]
SOLR-16368: Use SolrClient type instead of overly specific subclasses (#1012)
Replaced various subclasses of SolrClient such as HttpSolrClient,
Http2SolrClient, and CloudHttp2SolrClient with SolrClient where possible.
> Refactoring: Use SolrClient type instead of overly specific subclasses
> ----------------------------------------------------------------------
>
> Key: SOLR-16368
> URL: https://issues.apache.org/jira/browse/SOLR-16368
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
> Assignee: Eric Pugh
> Priority: Minor
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> There are many references to a specific SolrClient subclass that could simply
> refer to SolrClient generally, or perhaps CloudSolrClient. This impedes
> switching/migrating to different SolrClient implementations. A similar
> example: we know it's a bad practice to declare a List as ArrayList even when
> it is one; the idea here with SolrClient is the same.
> And furthermore, often times "var solrClient = ..." (or even "var solr =
> ...") is totally adequate in the Solr codebase within a method because the
> variable name adequately communicates the type. These sorts of changes
> should happen first, and then weaken type references in APIs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
