[
https://issues.apache.org/jira/browse/SOLR-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12764361#action_12764361
]
Yonik Seeley commented on SOLR-1449:
------------------------------------
OK, at this point, I've only been investigating how SOLR-919 relates to this
issue:
- There are enough issues that it doesn't look like SOLR-919 would be a quick
commit after 1.4 is released
1. SolrConfig is currently a mix of mutable / immutable - for example
CacheConfig contains cumulative stats (in addition to the resource loader of
course)
2. 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. They also
may want true singleton classes, which means a single class loader for their
class. Also, if one shares IndexSchema objects, etc, but doesn't share the
resource loader, isn't it weird that for a core, some of the objects will not
be from it's ResourceLoader? Starts smelling like "classloader hell" to me...
3. There is a lot of middle ground between using the exact same SolrConfig
objects and reparsing XML. For example, clone type functionallity could be
used to either create a new config from an existing one, or wrap a common core.
Immutable stuff could be shallowly copied, while mutable stuff could have
their own per-core instance.
- It doesn't seem like adding <lib> entries to solrconfig.xml will cause future
problems for SOLR-919 above and beyond what already exist
- It seems logical that configuration should be able to affect where/how
libraries are loaded.
Noble, if you agree with the last two points, do you have further objections to
the last patch that Hoss put up?
Does anyone else have objections to committing this if it's properly reviewed
by more people?
If no objections, I'll move on to actually reviewing and testing this patch
with the goal of committing it Monday morning. In fact I'll start soon
regardless because of the limited time and the async nature of our
communication.
> 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
>
>
> 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.
