[
https://issues.apache.org/jira/browse/SOLR-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski updated SOLR-8097:
----------------------------------
Attachment: SOLR-8097.patch
Ok, this removes all* uses of the now-deprecated constructors.
The asterisk above implies there are still a few cases where the constructors
are called.
- In {{SolrTestCaseJ4}}, where there are utility methods that randomly choose
whether to create clients using the builder, or the now-deprecated ctor.
- There are a few classes which have a private SolrClient subclass. In almost
all cases this is done to specify some alternate behavior for
{{SolrClient.handleError()}}. I changed these all to use the "largest" ctor
for the SolrClient they're extending (the ctor with all parameters, that will
be kept around with a reduced visibility after the other ctors are deleted.
I'm not sure I described the second case well, but if my description is
unclear, check out {{StreamingSolrClients.java}}, which has a good example of
this.
All other uses have been removed.
As a side note, in this last revision, I realized that deprecating, eventually
removing, and lowering the visibility of SolrClient ctors makes implementations
difficult to extend anonymously. This isn't a big deal. Just wanted to
mention it in case it bothers anyone.
This should be ready to go [~anshumg]!
> Implement a builder pattern for constructing a Solrj client
> -----------------------------------------------------------
>
> Key: SOLR-8097
> URL: https://issues.apache.org/jira/browse/SOLR-8097
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Affects Versions: master
> Reporter: Hrishikesh Gadre
> Assignee: Anshum Gupta
> Priority: Minor
> Attachments: SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch,
> SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch,
> SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch, SOLR-8097.patch,
> SOLR-8097.patch
>
>
> Currently Solrj clients (e.g. CloudSolrClient) supports multiple constructors
> as follows,
> public CloudSolrClient(String zkHost)
> public CloudSolrClient(String zkHost, HttpClient httpClient)
> public CloudSolrClient(Collection<String> zkHosts, String chroot)
> public CloudSolrClient(Collection<String> zkHosts, String chroot, HttpClient
> httpClient)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders)
> public CloudSolrClient(String zkHost, boolean updatesToLeaders, HttpClient
> httpClient)
> It is kind of problematic while introducing an additional parameters (since
> we need to introduce additional constructors). Instead it will be helpful to
> provide SolrClient Builder which can provide either default values or support
> overriding specific parameter.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
