[
https://issues.apache.org/jira/browse/SOLR-11629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Gerlowski resolved SOLR-11629.
------------------------------------
Resolution: Fixed
Fix Version/s: master (8.0)
7.3
> CloudSolrClient.Builder should accept a zk host
> -----------------------------------------------
>
> Key: SOLR-11629
> URL: https://issues.apache.org/jira/browse/SOLR-11629
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Varun Thacker
> Assignee: Jason Gerlowski
> Priority: Major
> Fix For: 7.3, master (8.0)
>
> Attachments: SOLR-11629.patch, SOLR-11629.patch, SOLR-11629.patch,
> SOLR-11629.patch, SOLR-11629.patch
>
>
> Today we need to create an empty builder and then wither pass zkHost or
> withSolrUrl
> {code}
> SolrClient solrClient = new
> CloudSolrClient.Builder().withZkHost("localhost:9983").build();
> solrClient.request(updateRequest, "gettingstarted");
> {code}
> What if we have two constructors , one that accepts a zkHost and one that
> accepts a SolrUrl .
> The advantages that I can think of are:
> - It will be obvious to users that we support two mechanisms of creating a
> CloudSolrClient . The SolrUrl option is cool and applications don't need to
> know about ZooKeeper and new users will learn about this . Maybe our
> example's on the ref guide should use this?
> - Today people can set both zkHost and solrUrl but CloudSolrClient can only
> utilize one of them
> HttpClient's Builder accepts the host
> {code}
> HttpSolrClient client = new
> HttpSolrClient.Builder("http://localhost:8983/solr";).build();
> client.request(updateRequest, "techproducts");
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
