[
https://issues.apache.org/jira/browse/SOLR-15342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17436529#comment-17436529
]
Jan Høydahl commented on SOLR-15342:
------------------------------------
I think there are two ways we can do this. One is to move all code with
compile-time ZK dependencies into separate classes, and make sure our
CloudSolrClient classes only work on interfaces, such as the
ClusterStateProvider. Our current code is not very clean, so there are direct
use of e.g. ZkStateReader and zookeeper settings all over the place such as in
BaseCloudSolrClient.
A slightly less clean way is to keep some compile-time deps but not announce
them in the pom, so that users will get ClassNotFoundException unless a
separate solrj-zookeeper jar is also added to classpath.
I realize that internal/inter-node use of SolrJ relies on ZK and that must
remain somehow. I think perhaps it would be cleaner to have a CloudSolr2Client
without any zk deps, and a separate CloudSolr2ClientZk that would be used
internally or by expert external users.
It is unrealistic to prepare for this in 8.x, so I propose that we use the 9.x
line to come up with a new architecture, where current
org.apache.solr:solr-solrj artifact is kept and then we add new refactored
clients and deprecate old ones.
> Separate out a SolrJ-Zookeeper module
> -------------------------------------
>
> Key: SOLR-15342
> URL: https://issues.apache.org/jira/browse/SOLR-15342
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
> Reporter: David Smiley
> Priority: Major
>
> Let's create a new "SolrJ-Zookeeper" module by refactoring out the ZooKeeper
> related code out of the existing SolrJ module. This allows clients that
> don't want to talk to ZooKeeper to use the SolrJ module without transitive
> dependencies for ZooKeeper or Netty (Netty is used by ZK for SSL).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
