[jira] [Commented] (SOLR-3526) Remove classfile dependency on ZooKeeper from CoreContainer
[ https://issues.apache.org/jira/browse/SOLR-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15094971#comment-15094971 ] ASF GitHub Bot commented on SOLR-3526: -- Github user msfroh closed the pull request at: https://github.com/apache/lucene-solr/pull/211 > Remove classfile dependency on ZooKeeper from CoreContainer > --- > > Key: SOLR-3526 > URL: https://issues.apache.org/jira/browse/SOLR-3526 > Project: Solr > Issue Type: Wish > Components: SolrCloud >Affects Versions: 4.0-ALPHA >Reporter: Michael Froh > > We are using Solr as a library embedded within an existing application, and > are currently developing toward using 4.0 when it is released. > We are currently instantiating SolrCores with null CoreDescriptors (and hence > no CoreContainer), since we don't need SolrCloud functionality (and do not > want to depend on ZooKeeper). > A couple of months ago, SearchHandler was modified to try to retrieve a > ShardHandlerFactory from the CoreContainer. I was able to work around this by > specifying a dummy ShardHandlerFactory in the config. > Now UpdateRequestProcessorChain is inserting a DistributedUpdateProcessor > into my chains, again triggering a NPE when trying to dereference the > CoreDescriptor. > I would happily place the SolrCores in CoreContainers, except that > CoreContainer imports and references org.apache.zookeeper.KeeperException, > which we do not have (and do not want) in our classpath. Therefore, I get a > ClassNotFoundException when loading the CoreContainer class. > Ideally (IMHO), ZkController should isolate the ZooKeeper dependency, and > simply rethrow KeeperExceptions as > org.apache.solr.common.cloud.ZooKeeperException (or some Solr-hosted checked > exception). Then CoreContainer could remove the offending import/references. -- 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
[jira] [Commented] (SOLR-3526) Remove classfile dependency on ZooKeeper from CoreContainer
[ https://issues.apache.org/jira/browse/SOLR-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15064657#comment-15064657 ] Mark Miller commented on SOLR-3526: --- I'm not sure we want to deal with those kinds of restrictions. Solr has many dependencies and ZK is not a particularly large one. I don't see why it should get special attention or special rules. > Remove classfile dependency on ZooKeeper from CoreContainer > --- > > Key: SOLR-3526 > URL: https://issues.apache.org/jira/browse/SOLR-3526 > Project: Solr > Issue Type: Wish > Components: SolrCloud >Affects Versions: 4.0-ALPHA >Reporter: Michael Froh > > We are using Solr as a library embedded within an existing application, and > are currently developing toward using 4.0 when it is released. > We are currently instantiating SolrCores with null CoreDescriptors (and hence > no CoreContainer), since we don't need SolrCloud functionality (and do not > want to depend on ZooKeeper). > A couple of months ago, SearchHandler was modified to try to retrieve a > ShardHandlerFactory from the CoreContainer. I was able to work around this by > specifying a dummy ShardHandlerFactory in the config. > Now UpdateRequestProcessorChain is inserting a DistributedUpdateProcessor > into my chains, again triggering a NPE when trying to dereference the > CoreDescriptor. > I would happily place the SolrCores in CoreContainers, except that > CoreContainer imports and references org.apache.zookeeper.KeeperException, > which we do not have (and do not want) in our classpath. Therefore, I get a > ClassNotFoundException when loading the CoreContainer class. > Ideally (IMHO), ZkController should isolate the ZooKeeper dependency, and > simply rethrow KeeperExceptions as > org.apache.solr.common.cloud.ZooKeeperException (or some Solr-hosted checked > exception). Then CoreContainer could remove the offending import/references. -- 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
[jira] [Commented] (SOLR-3526) Remove classfile dependency on ZooKeeper from CoreContainer
[ https://issues.apache.org/jira/browse/SOLR-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15064558#comment-15064558 ] Tomás Fernández Löbbe commented on SOLR-3526: - I think the change makes sense, it's a valid concern that people using EmbeddedSolrServer doesn't want ZooKeeper dependencies. I'm wondering if there is an easy way to test this so that dependencies are not inadvertently added later. > Remove classfile dependency on ZooKeeper from CoreContainer > --- > > Key: SOLR-3526 > URL: https://issues.apache.org/jira/browse/SOLR-3526 > Project: Solr > Issue Type: Wish > Components: SolrCloud >Affects Versions: 4.0-ALPHA >Reporter: Michael Froh > > We are using Solr as a library embedded within an existing application, and > are currently developing toward using 4.0 when it is released. > We are currently instantiating SolrCores with null CoreDescriptors (and hence > no CoreContainer), since we don't need SolrCloud functionality (and do not > want to depend on ZooKeeper). > A couple of months ago, SearchHandler was modified to try to retrieve a > ShardHandlerFactory from the CoreContainer. I was able to work around this by > specifying a dummy ShardHandlerFactory in the config. > Now UpdateRequestProcessorChain is inserting a DistributedUpdateProcessor > into my chains, again triggering a NPE when trying to dereference the > CoreDescriptor. > I would happily place the SolrCores in CoreContainers, except that > CoreContainer imports and references org.apache.zookeeper.KeeperException, > which we do not have (and do not want) in our classpath. Therefore, I get a > ClassNotFoundException when loading the CoreContainer class. > Ideally (IMHO), ZkController should isolate the ZooKeeper dependency, and > simply rethrow KeeperExceptions as > org.apache.solr.common.cloud.ZooKeeperException (or some Solr-hosted checked > exception). Then CoreContainer could remove the offending import/references. -- 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
[jira] [Commented] (SOLR-3526) Remove classfile dependency on ZooKeeper from CoreContainer
[ https://issues.apache.org/jira/browse/SOLR-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15014167#comment-15014167 ] Michael Froh commented on SOLR-3526: Also worth highlighting -- the significant part of the change mostly involves decorating ZooKeeper calls in SolrZkClient to catch KeeperExceptions and rethrow as appropriately-typed SolrZkCheckedExceptions, I decorated those calls by turning them into lambdas. So, the change can't easily be backported to 5.x. More significantly, I suppose, I changed the method signatures of about a hundred methods, which probably prevents backporting anyway. > Remove classfile dependency on ZooKeeper from CoreContainer > --- > > Key: SOLR-3526 > URL: https://issues.apache.org/jira/browse/SOLR-3526 > Project: Solr > Issue Type: Wish > Components: SolrCloud >Affects Versions: 4.0-ALPHA >Reporter: Michael Froh > > We are using Solr as a library embedded within an existing application, and > are currently developing toward using 4.0 when it is released. > We are currently instantiating SolrCores with null CoreDescriptors (and hence > no CoreContainer), since we don't need SolrCloud functionality (and do not > want to depend on ZooKeeper). > A couple of months ago, SearchHandler was modified to try to retrieve a > ShardHandlerFactory from the CoreContainer. I was able to work around this by > specifying a dummy ShardHandlerFactory in the config. > Now UpdateRequestProcessorChain is inserting a DistributedUpdateProcessor > into my chains, again triggering a NPE when trying to dereference the > CoreDescriptor. > I would happily place the SolrCores in CoreContainers, except that > CoreContainer imports and references org.apache.zookeeper.KeeperException, > which we do not have (and do not want) in our classpath. Therefore, I get a > ClassNotFoundException when loading the CoreContainer class. > Ideally (IMHO), ZkController should isolate the ZooKeeper dependency, and > simply rethrow KeeperExceptions as > org.apache.solr.common.cloud.ZooKeeperException (or some Solr-hosted checked > exception). Then CoreContainer could remove the offending import/references. -- 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
[jira] [Commented] (SOLR-3526) Remove classfile dependency on ZooKeeper from CoreContainer
[ https://issues.apache.org/jira/browse/SOLR-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15014134#comment-15014134 ] Michael Froh commented on SOLR-3526: 3.5 years later, I decided to try taking a stab at this myself. In the meantime, references to KeeperException and ZooKeeper's Stat class have worked there way through core Solr classes, including SolrCore and RequestParams. After making these changes, I was able (from a clean work space) to successfully run the tests from TestEmbeddedSolrServerConstructors (removing the "extends SolrTestCaseJ4") without ZooKeeper on my classpath. (I couldn't extend SolrTestCaseJ4, since RevertDefaultThreadHandlerRule references org.apache.zookeeper.server.NIOServerCnxnFactory.) I'm not sure how to add a test to the Solr build that will verify that someone is able to bring up an EmbeddedSolrServer and use core features without ZooKeeper. Does anyone have any suggestions? > Remove classfile dependency on ZooKeeper from CoreContainer > --- > > Key: SOLR-3526 > URL: https://issues.apache.org/jira/browse/SOLR-3526 > Project: Solr > Issue Type: Wish > Components: SolrCloud >Affects Versions: 4.0-ALPHA >Reporter: Michael Froh > > We are using Solr as a library embedded within an existing application, and > are currently developing toward using 4.0 when it is released. > We are currently instantiating SolrCores with null CoreDescriptors (and hence > no CoreContainer), since we don't need SolrCloud functionality (and do not > want to depend on ZooKeeper). > A couple of months ago, SearchHandler was modified to try to retrieve a > ShardHandlerFactory from the CoreContainer. I was able to work around this by > specifying a dummy ShardHandlerFactory in the config. > Now UpdateRequestProcessorChain is inserting a DistributedUpdateProcessor > into my chains, again triggering a NPE when trying to dereference the > CoreDescriptor. > I would happily place the SolrCores in CoreContainers, except that > CoreContainer imports and references org.apache.zookeeper.KeeperException, > which we do not have (and do not want) in our classpath. Therefore, I get a > ClassNotFoundException when loading the CoreContainer class. > Ideally (IMHO), ZkController should isolate the ZooKeeper dependency, and > simply rethrow KeeperExceptions as > org.apache.solr.common.cloud.ZooKeeperException (or some Solr-hosted checked > exception). Then CoreContainer could remove the offending import/references. -- 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
[jira] [Commented] (SOLR-3526) Remove classfile dependency on ZooKeeper from CoreContainer
[ https://issues.apache.org/jira/browse/SOLR-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15014121#comment-15014121 ] ASF GitHub Bot commented on SOLR-3526: -- GitHub user msfroh opened a pull request: https://github.com/apache/lucene-solr/pull/211 SOLR-3526: Remove classfile dependency on ZK for core Solr classes Replace references to o.a.z.KeeperException with a Solr-owned exception and push uses of o.a.z.data.Stat into ZkController, so that users of vanilla Solr (not SolrCloud) don't need to have ZooKeeper in their classpath. You can merge this pull request into a Git repository by running: $ git pull https://github.com/msfroh/lucene-solr trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/211.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #211 commit 1d7c8c4cf8fb86c38a55ad544877a824efddec9f Author: Michael Froh Date: 2015-11-19T18:05:28Z SOLR-3526: Remove classfile dependency on ZK for core Solr classes Replace references to o.a.z.KeeperException with a Solr-owned exception and push uses of o.a.z.data.Stat into ZkController, so that users of vanilla Solr (not SolrCloud) don't need to have ZooKeeper in their classpath. > Remove classfile dependency on ZooKeeper from CoreContainer > --- > > Key: SOLR-3526 > URL: https://issues.apache.org/jira/browse/SOLR-3526 > Project: Solr > Issue Type: Wish > Components: SolrCloud >Affects Versions: 4.0-ALPHA >Reporter: Michael Froh > > We are using Solr as a library embedded within an existing application, and > are currently developing toward using 4.0 when it is released. > We are currently instantiating SolrCores with null CoreDescriptors (and hence > no CoreContainer), since we don't need SolrCloud functionality (and do not > want to depend on ZooKeeper). > A couple of months ago, SearchHandler was modified to try to retrieve a > ShardHandlerFactory from the CoreContainer. I was able to work around this by > specifying a dummy ShardHandlerFactory in the config. > Now UpdateRequestProcessorChain is inserting a DistributedUpdateProcessor > into my chains, again triggering a NPE when trying to dereference the > CoreDescriptor. > I would happily place the SolrCores in CoreContainers, except that > CoreContainer imports and references org.apache.zookeeper.KeeperException, > which we do not have (and do not want) in our classpath. Therefore, I get a > ClassNotFoundException when loading the CoreContainer class. > Ideally (IMHO), ZkController should isolate the ZooKeeper dependency, and > simply rethrow KeeperExceptions as > org.apache.solr.common.cloud.ZooKeeperException (or some Solr-hosted checked > exception). Then CoreContainer could remove the offending import/references. -- 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
[jira] [Commented] (SOLR-3526) Remove classfile dependency on ZooKeeper from CoreContainer
[ https://issues.apache.org/jira/browse/SOLR-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292689#comment-13292689 ] Michael Froh commented on SOLR-3526: Oh, thanks a lot for pointing that out, Hoss! I had completely missed that part. My wish for the removal of the KeeperException reference from CoreContainer still stands, but using NoOpDistributingUpdateProcessorFactory lets me remove my current hacky solution (adding a dummy org.apache.zookeeper.KeeperException in one of my libraries). > Remove classfile dependency on ZooKeeper from CoreContainer > --- > > Key: SOLR-3526 > URL: https://issues.apache.org/jira/browse/SOLR-3526 > Project: Solr > Issue Type: Wish > Components: SolrCloud >Affects Versions: 4.0 >Reporter: Michael Froh > > We are using Solr as a library embedded within an existing application, and > are currently developing toward using 4.0 when it is released. > We are currently instantiating SolrCores with null CoreDescriptors (and hence > no CoreContainer), since we don't need SolrCloud functionality (and do not > want to depend on ZooKeeper). > A couple of months ago, SearchHandler was modified to try to retrieve a > ShardHandlerFactory from the CoreContainer. I was able to work around this by > specifying a dummy ShardHandlerFactory in the config. > Now UpdateRequestProcessorChain is inserting a DistributedUpdateProcessor > into my chains, again triggering a NPE when trying to dereference the > CoreDescriptor. > I would happily place the SolrCores in CoreContainers, except that > CoreContainer imports and references org.apache.zookeeper.KeeperException, > which we do not have (and do not want) in our classpath. Therefore, I get a > ClassNotFoundException when loading the CoreContainer class. > Ideally (IMHO), ZkController should isolate the ZooKeeper dependency, and > simply rethrow KeeperExceptions as > org.apache.solr.common.cloud.ZooKeeperException (or some Solr-hosted checked > exception). Then CoreContainer could remove the offending import/references. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3526) Remove classfile dependency on ZooKeeper from CoreContainer
[ https://issues.apache.org/jira/browse/SOLR-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292082#comment-13292082 ] Hoss Man commented on SOLR-3526: I'll defer on the large topic to miller/yonik/sami, but as to a specific comment... bq. Now UpdateRequestProcessorChain is inserting a DistributedUpdateProcessor into my chains, again triggering a NPE when trying to dereference the CoreDescriptor. ...please note the updated javadocs for UpdateRequestProcessorChain.init... {noformat} /** * Initializes the chain using the factories specified by the PluginInfo. * if the chain includes the RunUpdateProcessorFactory, but * does not include an implementation of the * DistributingUpdateProcessorFactory interface, then an * instance of DistributedUpdateProcessorFactory will be * injected immediately prior to the RunUpdateProcessorFactory. * * @see DistributingUpdateProcessorFactory * @see RunUpdateProcessorFactory * @see DistributedUpdateProcessorFactory */ {noformat} ...and note the existence of NoOpDistributingUpdateProcessorFactory... {noformat} /** * A No-Op implementation of DistributingUpdateProcessorFactory that * allways returns null. * * This implementation may be useful for Solr installations in which neither * the {@link DistributedUpdateProcessorFactory} nor any custom * implementation of {@link DistributingUpdateProcessorFactory} * is desired (ie: shards are managed externally from Solr) * */ {noformat} > Remove classfile dependency on ZooKeeper from CoreContainer > --- > > Key: SOLR-3526 > URL: https://issues.apache.org/jira/browse/SOLR-3526 > Project: Solr > Issue Type: Wish > Components: SolrCloud >Affects Versions: 4.0 >Reporter: Michael Froh > > We are using Solr as a library embedded within an existing application, and > are currently developing toward using 4.0 when it is released. > We are currently instantiating SolrCores with null CoreDescriptors (and hence > no CoreContainer), since we don't need SolrCloud functionality (and do not > want to depend on ZooKeeper). > A couple of months ago, SearchHandler was modified to try to retrieve a > ShardHandlerFactory from the CoreContainer. I was able to work around this by > specifying a dummy ShardHandlerFactory in the config. > Now UpdateRequestProcessorChain is inserting a DistributedUpdateProcessor > into my chains, again triggering a NPE when trying to dereference the > CoreDescriptor. > I would happily place the SolrCores in CoreContainers, except that > CoreContainer imports and references org.apache.zookeeper.KeeperException, > which we do not have (and do not want) in our classpath. Therefore, I get a > ClassNotFoundException when loading the CoreContainer class. > Ideally (IMHO), ZkController should isolate the ZooKeeper dependency, and > simply rethrow KeeperExceptions as > org.apache.solr.common.cloud.ZooKeeperException (or some Solr-hosted checked > exception). Then CoreContainer could remove the offending import/references. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org