[
https://issues.apache.org/jira/browse/SOLR-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15527057#comment-15527057
]
Jason Gerlowski commented on SOLR-8975:
---------------------------------------
As an additional question/comment, the attached patch takes the values formerly
provided to various setters, and adds them as parameters to the current
"kitchen-sink" ctor (the one with all params used by the Builder). This is
technically a breaking change, as the ctor now has more arguments than it did
previously. Maybe this isn't a huge deal, as these "kitchen-sink" ctors have
already been deprecated.
But I suspect what I should do is change the patch to create _new_ deprecated
kitchen-sink ctors that incorporate all the setter params, and leave the
current (no longer "kitchen-sink") ctors as-is.
Just wanted to confirm that. If no one suggests otherwise, I'll make that
change shortly.
> SolrClient setters should be deprecated in favor of SolrClientBuilder methods
> -----------------------------------------------------------------------------
>
> Key: SOLR-8975
> URL: https://issues.apache.org/jira/browse/SOLR-8975
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Reporter: Jason Gerlowski
> Priority: Minor
> Attachments: SOLR-8975.patch
>
>
> SOLR-8097 added a builder layer on top of each {{SolrClient}} implementation.
> Now that builders are in place for SolrClients, the setters used in each
> SolrClient can be deprecated, and their functionality moved over to the
> Builders. This change brings a few benefits:
> - unifies SolrClient configuration under the new Builders. It'll be nice to
> have all the knobs, and levers used to tweak SolrClients available in a
> single place (the Builders).
> - reduces SolrClient thread-safety concerns. Currently, clients are mutable.
> Using some SolrClient setters can result in erratic and "trappy" behavior
> when the clients are used across multiple threads.
--
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
