[
https://issues.apache.org/jira/browse/SOLR-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12764546#action_12764546
]
Noble Paul commented on SOLR-1449:
----------------------------------
bq.It doesn't seem like adding <lib> entries to solrconfig.xml will cause
future problems for SOLR-919 above and beyond what already exist
I agree with the configuration . Though the regex seems to be an overkill .I am
yet to see why it would be useful. Moreover , it leaves ambiguity as to what
are the jars which got loaded .
bq.It seems logical that configuration should be able to affect where/how
libraries are loaded.
yes configuration should have a say of the libraries. But the configuration
should be a data structure. I see it as a source of information to the system.
This will enable users plugin there own SolrConfigs implementations (loaded
from external data sources zookeeper etc ).
bq.It's not clear to me that you want different resource loaders for each
shared SolrConfig - people would definitely want to avoid loading more than one
copy of dictionary based stemmers such as kstemmer or smart_cn.
SolrResourceLoader is a lightweight component. There is no need to couple it
with the fact whether SolrConfig is shared or not.
My patch is slightly awkward, But that was introduced because of the regex
option. Otherwise it would have been simpler. But ,overall , my patch
introduced fewer changes .
bq. SolrConfig is currently a mix of mutable / immutable - for example
CacheConfig contains cumulative stats (in addition to the resource loader of
course)
SolrConfig holds a reference to the SolrResourceLoader, but it never uses it
anywhere internally. The CacheConfig is an anomaly. But that can be rectified .
> solrconfig.xml syntax to add classpath elements from outside of instanceDir
> ---------------------------------------------------------------------------
>
> Key: SOLR-1449
> URL: https://issues.apache.org/jira/browse/SOLR-1449
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
> Assignee: Hoss Man
> Fix For: 1.5
>
> Attachments: SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch,
> SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch,
> SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch
>
>
> the idea has been discussed numerous times that it would be nice if there was
> a way to configure a core to load plugins from specific jars (or "classes"
> style directories) by path w/o needing to copy them to the "./lib" dir in
> the instanceDir.
> The current workaround is "symlinks" but that doesn't really help the
> situation of the Solr Release artifacts, where we wind up making numerous
> copies of jars to support multiple example directories (you can't have
> reliable symlinks in zip files)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
