[
https://issues.apache.org/jira/browse/SOLR-16368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622475#comment-17622475
]
Eric Pugh commented on SOLR-16368:
----------------------------------
I think that this is done as far as can be until we decide how, in our tests,
we want to deal with looking up an HttpClient, as that is why we typically are
using a more specific subclass. I am not sure how to make a decision on
that...
To make this more fun, there are quite a few ways of using the HttpClient
through out the code base:
{{try (HttpSolrClient cl = (HttpSolrClient) j.newClient()) {}}
{{ Utils.executeHttpMethod(cl.getHttpClient(), path, Utils.JSONCONSUMER,
del);}}
{{ }}}
and
{{ ByteBuffer buf =}}
{{ Utils.executeGET(}}
{{ solrClient.getHttpClient(),}}
{{ baseUrl + "/node/files" + path,}}
{{ Utils.newBytesConsumer(Integer.MAX_VALUE));}}
There are some refactorings we could do, for example the method
assertDocExists() and realTimeGetDocId() exists in many test classes. I will
take those refactorings forward....
> 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
> Fix For: main (10.0), 9.2
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
