[ 
https://issues.apache.org/jira/browse/SOLR-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761314#action_12761314
 ] 

Hoss Man commented on SOLR-1449:
--------------------------------

As i said: these aren't questions that we should be attempting to answer here - 
they are about the impacts of potential future features.

This patch works against the trunk _*today*_ ... SolrConfig currently maintains 
a reference to a SolrResourceLoader which it _may_ have instantiated itself in 
it's constructor, or it may have received it as a constructor argument -- 
either way this patch ensures that that SolrResourceLoader gets a consistent 
classloader based on the Configs that are parsed without needing to make any 
"initLibs" or "getLibs" style functions public or changing the contract of 
initializing SolrConfig/SolrResourceLoader.  Even if someone is doing funky old 
school embedded Solr code where they construct their own SolrConfig objects the 
<lib> config options will still work.

If SOLR-919 or SOLR-1293 require refactoring things so that a SolrConfig 
instance can be reused with different classloaders that's going to require 
eliminating some public constructors and Refactoring the contract of when/how a 
SolrResourceLoader is initialized -- when we do that we can worry about 
refactoring the code in this patch.


> 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.4
>
>         Attachments: 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.

Reply via email to