[
https://issues.apache.org/jira/browse/SOLR-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761925#action_12761925
]
Hoss Man commented on SOLR-1449:
--------------------------------
bq. Noble has been refactoring SolrConfig in SOLR-1198 with the end goal being
pluggable loading of SolrConfig
I understand Noble's goal(s) .. i'm actually really stoked to be moving in that
direction and look forward to people being able to provide/reuse their own
SolrConfig implementations which may not use XML at all...
bq. So we need to ask now what is the function of SolrConfig? Do we want it to
load/modify SolrResourceLoader objects or just be a representation of
configuration?
I disagree that we need to ask that question "now", in this issue ... that is
an important question for other issues (which you and Noble have already
referenced). Those issues are going to face tough decisions about how to deal
with the existing contracts of Solr config like all the methods it inherits
from Config (including getResourceLoader(), and openResource()) or the fact
that all of it's public constructors are expected to initialize a new
SolrResourceLoader.
When the time comes to make those tough decisions, we will have to make
non-back-compat changes to the contracts of SolrConfig and SolrResourceLoader,
and document a 'new' contract for how to properly initialize them. *THAT* is
the appropriate time (in my opinion) to worry about how we should refactoring
all the SolrResourceLoader initialization code -- but today, on the trunk,
SolrConfig is still responsible for initializing SolrResourceLoader in many
cases. The patch as i wrote it ensures that no matter how a SolrResourceLoader
is instantiated, or who instantiates it, if a SolrConfig instance is told to
use it, then it gets a class loader based on the options in that SolrConfig.
This is the simplest possible patch I could think of to make the change
desired. I deliberately avoided making any public API changes to SolrCOnfig or
SolrResourceLoader because i didn't want to commit to who/how the ClassLoader
would get those changes -- so in the future (when we have to make/advertise big
API changes to SolrConfig to eliminate direct references to SOlrResourceLoader
anyway) it will be easy to refactor it (the logic in initLibs) to someplace
else and document exactly how the SolrResourceLoader should be initialized
cleanly.
At this point, i personally have no interest in trying to "guess" what the
right decisions will be down the road, nor am i interested in writing a more
complicated patch that would commit us to that guess with modifications
SolrConfig's public API. As i said in a previous comment...
bq. if you have any specific suggested improvements for the patch that you
think will make eventual work on SOLR-919 easier, then i'm all ears
...but to be more explicit: attach an alternate patch, and i'll review it.
> 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.
