Here is the branch with the code that I worked on this evening: https://github.com/apache/solr/pull/1158
It’s listed as SOLR-16368-experiment-with-builder-to-simplify-client-creation, however that is because I didn’t know about SOLR-8975…. ;-). I would love some more eyes on it. > On Nov 1, 2022, at 6:32 PM, David Smiley <[email protected]> wrote: > > I think it would be beneficial for SolrClient to be immutable. Users > cache/pool them (even Solr itself via SolrClientCache) which can lead to > problems if somewhere code mutates them after they've been published. > SolrClients have Builders so we're already on the path to make this happen. > > Years ago, Jason created a JIRA issue about this very thing: > https://issues.apache.org/jira/browse/SOLR-8975 > but it's rather hard, particularly across so many Solr tests that do > manipulations all over the place. I like that it's decomposed into > sub-JIRAs. These could easily be "newdev", by the way. > > Eric Pugh (unaware of SOLR-8975) started pulling a thread on this sweater, > and we've been chatting a bit about it. Anyway, I'm just posting here for > general awareness of the direction we're going in with SolrJ. Changes to > SolrJ are a high touch-point for our users so better to publicize. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley _______________________ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
