lucene-solr-dev mailing list archives

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

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


Mime
View raw message