[
https://issues.apache.org/jira/browse/SOLR-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-1449:
---------------------------
Attachment: SOLR-1449.patch
bq. I understand you want to make a core's lib directory configurable. That is
fine. It is the regex based loading that makes me nervous. Why not load all
jars in a specified directory?
The way you worded that is part of what i'm trying to fix: "a core's lib
directroy" ... i'm not trying to make the path of a single directory
configurable, i'm trying to eliminate the idea that there is a single "lib" dir
for a core -- people should be able to load any jars they want, from anywhere
they want.
The regex based selection already supported loading all files in a directory --
that's the default behavior if no regex is selected -- but in general there are
two main reasons i can think of why we should have regex (or glob) support...
1) so people don't have to load every jar in a directory just to get some of
those jars.
slurping up every file in ./lib was fine when we were forcing people to
manually create a directory inside the instance dir (if you don't want it
loaded don't copy it), but if we're trying to be flexible and allow people to
point at jars anywhere then we shouldn't hobble them by making them get
everything in a directory. it should be possible to have an assload of jars in
a big directory and say i only want this subset for this core.
2) so people don't have to hardcode jar version info.
people should have an easy way to say "load the tika jar" in their config, and
it should still work even if they delete apache-tika-0.4.jar and repalce it
with apache-tika-0.5.jar. I don't want to make them hardcode names.
---
I'm not sure why regex matching on filenames makes you "nervous" ... my best
guess is that you're worried regex mistakes silently not loading the files
(since a regex was the only way to laod a single jar explicitly) so in this
newest patch i've added support for a "path" options instead of dir+regex ...
if an explicitly path is used and it can't be found it's logged as an error....
{noformat}
<!-- all files in dir -->
<lib dir="../../dist/solr-cell-lib/" />
<!-- all files in dir matching the regex -->
<lib dir="../../dist/" regex="apache-solr-cell-(\d|\.)+-.*\.jar" />
<!-- nothing matches, so will be ignored -->
<lib dir="/total/crap/dir/ignored" />
<!-- an exact path (jar or classes dir), will log error if not found -->
<lib path="../a-jar-that-does-not-exist.jar" />
{noformat}
This patch also makes the changes i described in my previous comment (removing
the dependency on the order that the 'lib' dirs are declared)
> 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
> Fix For: 1.4
>
> Attachments: 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.
