[jira] [Commented] (SOLR-3526) Remove classfile dependency on ZooKeeper from CoreContainer

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[JIRA]

[ 
https://issues.apache.org/jira/browse/SOLR-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Michael Froh (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Michael Froh (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Michael Froh (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

[Hoss Man (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 
codePluginInfo/code.
   * if the chain includes the codeRunUpdateProcessorFactory/code, but 
   * does not include an implementation of the 
   * codeDistributingUpdateProcessorFactory/code interface, then an 
   * instance of codeDistributedUpdateProcessorFactory/code will be 
   * injected immediately prior to the codeRunUpdateProcessorFactory/code.
   *
   * @see DistributingUpdateProcessorFactory
   * @see RunUpdateProcessorFactory
   * @see DistributedUpdateProcessorFactory
   */
{noformat}

...and note the existence of NoOpDistributingUpdateProcessorFactory...

{noformat}
/**
 * A No-Op implementation of DistributingUpdateProcessorFactory that 
 * allways returns null.
 * p 
 * This implementation may be useful for Solr installations in which neither 
 * the code{@link DistributedUpdateProcessorFactory}/code nor any custom 
 * implementation of code{@link DistributingUpdateProcessorFactory}/code 
 * is desired (ie: shards are managed externally from Solr)
 * /p
 */
{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