[
https://issues.apache.org/jira/browse/SOLR-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762723#action_12762723
]
Hoss Man commented on SOLR-1449:
--------------------------------
bq. add a new method to SolrConfig ... public List<String> getPaths() .. in the
SolrResourceLoader we may just need an extra method addPath(String path)
I feel like we keep going around in circles on this, i don't know how to
express myself any better...
1) there should never be a public addPath(String) method on SOlrResourceLoader
... the ClassLoader should be initialized completely before the
SolrResourceLoader is used, or really wacky inconsistent classloader behavior
can result.
2) ideally SolrResourceLoader should require that all URLs for the ClassLoader
be specified in it's constructor, so we can keep the ClassLoader final -- but
given the existing COnstructors for SOlrCOnfig that's impossible (sometimes the
SolrConfig constructs the SolrResourceLoader, other times the caller constructs
the SolrResourceLoader, and then passes it as an argument to the SolrConfig
constructor) so in this patch i focused on keeping the changes as minimal as
possible, and not altering the public API.
3) Because of these multiple ways the SolrResourceLoader can be initialized,
the SolrCOnfig constructor is in the best position to ensure that the
ClassLoader URLs are added as early as possible.
4) We could add a "getPaths() method to SolrConfig -- but for
back-compatibility we would still need to set those paths on the
SolrResourceLoader in the SolrConfig constructor for embedded SOlr users people
who might be initializing things in a different order then we do in
CoreContainer.
5) someday, in order to achieve all of the various SolrConfig
simplification/reuse goals that have been discussed, we are going to need to
make non-back-compat changes to eliminate all references to SolrResourceLoader
from SolrConfig -- including eliminating all of the current public constructors
from SolrConfig (because they construct a SolrResourceLoader) and then, since
everyone will have to change how the instantiate SolrCOnfig objects anyway, it
will be easy to change the semantics of initializing a
SOlrConfig+SolrCore+SolrResourceLoader so that they make more sense...
{code}
SolrCofig config = new SolrConfig(...)
SolrResourceLoader loader = new SolrResourceLoader(cofig.getLibPaths(), ...)
...
SolrCore = new SolrCore(config, loader, ...)
{code}
...and when we reach that point it will be *trivial* to refactor the code added
by this patch so that it works that way, because at this point it is all nicely
self contained in package protected methods.
...
All of this reasoning is why i keep saying: it's a waste of time to worry about
how this code will impact reusable SolrCOnfig options in the _future_ since
it's all non-public and can be refactored at any time.
If someone wants to take my patch and refactor it _now_ then be my guest ...
but unless you plan on massively increasing the scope to completely sever the
direct connection between SolrCOnfig and SOlrResourceLoader i can't imagine how
adding SolrCOnfig.getPaths() and making someone besides SOlrConfig responsible
for passing those paths to SolrResourceLoader wlll result in a patch that would
be any cleaner or easier to maintain moving forward. ... but i'll be happy to
get proven wrong.
> 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,
> 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.
