lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Gerlowski (JIRA)" <>
Subject [jira] [Updated] (SOLR-8097) Implement a builder pattern for constructing a Solrj client
Date Sun, 14 Feb 2016 12:47:18 GMT


Jason Gerlowski updated SOLR-8097:
    Attachment: SOLR-8097.patch

Ok, so after a bit of a delay, I've got an updated patch which attempts to incorporate Shawn
and Anshum's input.

h3. In This Patch
- builder types for CloudSolrClient, LBHttpSolrClient, HttpSolrClient, and ConcurrentUpdateSolrClient.
- two abstract types which enabled some sharing of setters: {{HttpClientBasedSolrClientBuilder}},
and {{ResponseParserBasedSolrClientBuilder}}.  I say  _some_ , because while the inheritance-chain-to-allow-shared-setters
sounded like a great idea, it turned out to be tough in practice.  Only one param was present
in all builders (HttpClient).  Others were more hit-and-miss, which made getting good re-use
hard in Java's single-inheritance world.

h3. Not In This Patch
- Good Javadocs
- Much testing.
- Any deprecation notes.
- Internal usage of these builder types in SolrJ.

I plan on eventually adding items in the list above, but I wanted to get some feedback on
the builder class structure before continuing.  [~elyograg], are you happy with the re-use
I was able to get from things here?  It was your suggestion, so just wanted to make sure I
was faithful to your idea and didn't misinterpret what you wanted.

(Patch is on top of latest trunk.)

> Implement a builder pattern for constructing a Solrj client
> -----------------------------------------------------------
>                 Key: SOLR-8097
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>          Components: SolrJ
>    Affects Versions: master
>            Reporter: Hrishikesh Gadre
>            Priority: Minor
>         Attachments: 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message