lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shawn Heisey (JIRA)" <>
Subject [jira] [Commented] (SOLR-6681) remove <lib> configurations from solrconfig.xml and eliminate per core class loading
Date Sun, 02 Nov 2014 18:12:33 GMT


Shawn Heisey commented on SOLR-6681:

I think it's a good idea to get rid of <lib> configuration tags and put all jars in
one place.  How to manage that in the example without having duplicates of jars already present
in "dist" (and making the already bulky download even larger) is one of the thorny problems
we face.  The bin/solr script could copy or move jars the first time it runs ... which might
open a whole new set of problems, particularly when it is upgrade time.

I don't think we need to use an "ext" directory.  Solr already has a "default" classpath that
gets loaded without any configuration -- SOLRHOME/lib.  Whether or not we rename that from
lib to ext is something we could bikeshed about forever, so I'm inclined to go with inertia
and leave it alone.

SOLR-4852 describes some weird and irritating problems I've had related to this lib directory.

> remove <lib> configurations from solrconfig.xml and eliminate per core class loading
> ------------------------------------------------------------------------------------
>                 Key: SOLR-6681
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Noble Paul
> As Solr moves more towards cloud ,solrconfig is stored in Zookeeper. Storing the local
library information in a file stored in a remote and common location for all nodes make no
> In this new world, cores are created and managed by the solrcloud system and  there is
no need to have separate classloading for each core and a lot of unnecessary classloading
issues in solr can go away
> Going forward, all cores in a node will have only one classpath. We may define a standard
directory such as 'ext' under the HOME and let users store all their jars there

This message was sent by Atlassian JIRA

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

View raw message