[
https://issues.apache.org/jira/browse/SOLR-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15485336#comment-15485336
]
Shawn Heisey commented on SOLR-8097:
------------------------------------
What is your *specific* goal in creating a subclass? I ask because the X is
usually more important than the Y. See this:
http://people.apache.org/~hossman/#xyproblem
A SolrClient object is a complex thing, particularly the Cloud version.
Although we try to keep the public API from changing much in minor releases,
the internal implementation is a VERY different story. Because the
implementation can change dramatically from release to release, certain details
are kept private. This reduces the risk of breaking user code.
That said, there really is no reason we should *prevent* subclassing like we
currently do, even if we recommend not doing it because it makes user code
brittle.
It makes sense to change the kitchen-sink constructor from private to
protected. SOLR-8975 might be a good place to tackle this, but it might need
its own issue.
I think we should also recommend extending the Builder when subclassing. When
7.0 is released, all public constructors will be gone, and the Builder will be
the *only* way to create a client object.
> 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: 6.0
> Reporter: Hrishikesh Gadre
> Assignee: Anshum Gupta
> Fix For: 6.2, master (7.0)
>
> 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, 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: [email protected]
For additional commands, e-mail: [email protected]
