[
https://issues.apache.org/jira/browse/SOLR-6681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14193974#comment-14193974
]
Jan Høydahl commented on SOLR-6681:
-----------------------------------
+1 to the overall idea
Long-term solution would be a better plugin architecture to keep dependencies
for certain features in self-contained zip files, see SOLR-5103
Perhaps a short-term improvement if is Solr parses {{$SOLRHOME/lib}}
recursively for jars, then users could freely organize their jars in sub
folders and thus keep track of what jars belong together, for what feature etc
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
