[
https://issues.apache.org/jira/browse/SOLR-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12764688#action_12764688
]
Yonik Seeley commented on SOLR-1449:
------------------------------------
bq. Though the regex seems to be an overkill
Sure... but regex is built into Java and globbing is not. Comments in the code
say we should implement globbing in the future.
And since the regex is specified via the "regex" attribute (as opposed to the
value of an XML element) it's perfectly extensible in the future.
bq. the configuration should be a data structure. I see it as a source of
information to the system.
Configuration can also have behavior. The important part is that is the
separation from XML and allowing others to create configuration objects.
bq. SolrResourceLoader is a lightweight component. There is no need to couple
it with the fact whether SolrConfig is shared or not.
Just bringing up that it's not lightweight if has a separate classloader that
loads heavyweight things, and separate classloaders don't sound like they will
work well with cached Schemas... seems like they at least need a common
classloader parent for anything loaded by the schema.
bq. But ,overall , my patch introduced fewer changes .
That's not true though... Hoss pointed out the risk for embedded users. And it
seems like you were bit by this yourself - see CoreContainer.create()... the
Schema is created *before* the SolrCore is, and thus would not have been using
the right classloader.
bq. SolrConfig holds a reference to the SolrResourceLoader, but it never uses
it anywhere internally.
See above - the schema uses the loader from SolrConfig.
> 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.
