lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noble Paul (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-1449) solrconfig.xml syntax to add classpath elements from outside of instanceDir
Date Mon, 12 Oct 2009 04:50:31 GMT

    [ 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.


Mime
View raw message