lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] Updated: (SOLR-1449) solrconfig.xml syntax to add classpath elements from outside of instanceDir
Date Fri, 25 Sep 2009 00:40:16 GMT

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


Mime
View raw message