You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Shawn Heisey (JIRA)" <ji...@apache.org> on 2014/11/02 19:12:33 UTC

[jira] [Commented] (SOLR-6681) remove configurations from solrconfig.xml and eliminate per core class loading

    [ https://issues.apache.org/jira/browse/SOLR-6681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14193941#comment-14193941 ] 

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: https://issues.apache.org/jira/browse/SOLR-6681
>             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 sense. 
> 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
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org