[
https://issues.apache.org/jira/browse/SOLR-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15091257#comment-15091257
]
Jason Gerlowski commented on SOLR-8097:
---------------------------------------
My comment above implies some questions about the measures we try to take in
ensuring backward-compatibility in SolrJ code. I'm still new to the Solr
community, so I'm not quite sure how things are typically done here.
My assumption up to this point is that core SolrJ APIs (i.e. Java ctor/method
signatures) can only be changed by a major release. (This appears to have been
confirmed by most of the discussion on the recent "Breaking Java back-compat in
Solr" mailing list thread, by my reading of it at least.)
I'm also a little unclear on what "deprecation" means within the Solr
community. Can a deprecation warning appear on a non-major release? How long
does a deprecation warning typically stay around before the API can be removed
altogether? Anyone have a pointer to an article/wiki where I can read up on
this?
That said, this isn't relevant/necessary to start working on a patch, as long
as I don't touch any of the existing ctors. So that's how I'll go forward with
things until I hear feedback otherwise. I'll start putting together a
purely-additive patch off of trunk later tonight or tomorrow.
> 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: Trunk
> Reporter: Hrishikesh Gadre
> Priority: Minor
>
> 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]
