[
https://issues.apache.org/jira/browse/SOLR-16368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608867#comment-17608867
]
David Smiley commented on SOLR-16368:
-------------------------------------
For a bit I was thinking maybe we need some base HTTP SolrClient abstraction
because of this. But then it's just one method and it's nearly all tests that
even want to call it. So I'm sympathetic to your proposal, even though it sort
of doesn't look great by itself. It could try checking for both the Apache &
Jetty based HTTP clients. I guess the down side is that we'd be declaring
SolrClient in a lot of spots in tests when in fact the test actually does
require a specific type. But it'd support both types and it's just tests -- it
will fail if someone attempts to call it with a non-supported type, and they'll
fix their test.
> 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: 50m
> 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]
