configs, plugins, and index location

[Chris Hostetter <ho...@fucit.org>]

On the subject of how Solr can find user supplied files (without the user
unpacking the WAR and copying them into the WEB-INF/classes) ...

I'm of the opinion that searching the CLASSPATH for "solrconfig.xml"
directly is fine, and any plugin class/jars can work the same way --
Solr's web.xml should stop trying to add ../../conf/solar/WEB-INF/classes
and ../../conf/solar/WEB-INF/lib, clients can just make sure the directory
they've got their solarconfig.xml is in the classpath when they start the
server.

Once the solrconfig is loaded -- a lot becomes easier ... the index
directory and the schema.xml path can be specified there, as absolute
paths or relative if that's what the client wants to use.

(of course, there's still the issue of XSLT stylesheets... dang.



That said ... I can't believe other webapp applications don't have this
problem too ... how do most apps distributed as a WAR deal with their
configuration in a server agnostic way?


-Hoss

Re: configs, plugins, and index location

[Yonik Seeley <ys...@gmail.com>]

On 2/8/06, Chris Hostetter <ho...@fucit.org> wrote:
> i thought the concensous was that using
> the current working directory was unsafe and had to be avoied.

Using cwd is OK as an option or a default, but there should be other
ways to configure it that don't rely on cwd for production
environments if one doesn't have tight control over the cwd that an
appserver is started from.

What that other way is hasn't been fully flushed out IMO.  One
possibility is explicitly adding the conf directory to the classpath
before starting the server.

-Yonik

Re: configs, plugins, and index location

[Chris Hostetter <ho...@fucit.org>]

: I've already committed patches to look in ./conf for text files
: (solrconfig.xml, schema.xml, etc), and to assume that ./data/index
: will contain the lucene index.
: If config files aren't found in ./conf, the classpath will be checked.
:
: The motivation was limiting the number of steps that a new user has to
: do before getting something up and running.

Oh ... okay ... sorry, i'm totally on board with this approach, I must
have missread the past discussion, i thought the concensous was that using
the current working directory was unsafe and had to be avoied.

: files like the schema though.  I'm inclined to punt that until someone
: actually needs solarconfig.xml and schema.xml in different places.

+1

: > That said ... I can't believe other webapp applications don't have this
: > problem too ... how do most apps distributed as a WAR deal with their
: > configuration in a server agnostic way?
:
: Our closest cousin, nutch, uses the CWD to find it's segments at least.

I wasn't even thinking about "similar" webapps ... i just mean, if
somebody out there writes a resume tracking applicaiton, or a blog
application and they distribute it as a war, how do they deal with user
configuration? ... they might make put everything in a database, or have a
GUI for specifying all of the config options -- including what
directory/DB to store config options in.  but once the app shuts down and
gets restarted, how do they know which DB to connect to or which directory
to look in?

The only experience I have with WARs at this point is at CNET where we
control the WAR and the configs -- anything that doesn't vary across
installation goes in the web.xml, and anything that does goes in a
web.external.xml which is not packaged in the WAR and gets included by the
web.xml using a fixed path that we know we can count on because we've made
sure *our* packaging of resin/tomcat/whatever supports it.

How to apps designed to work in any servlet container solve this problem?



-Hoss

Re: configs, plugins, and index location

[Yonik Seeley <ys...@gmail.com>]

On 2/8/06, Chris Hostetter <ho...@fucit.org> wrote:
> I'm of the opinion that searching the CLASSPATH for "solrconfig.xml"
> directly is fine

I've already committed patches to look in ./conf for text files
(solrconfig.xml, schema.xml, etc), and to assume that ./data/index
will contain the lucene index.
If config files aren't found in ./conf, the classpath will be checked.

The motivation was limiting the number of steps that a new user has to
do before getting something up and running.

> , and any plugin class/jars can work the same way --
> Solr's web.xml should stop trying to add ../../conf/solar/WEB-INF/classes
> and ../../conf/solar/WEB-INF/lib, clients can just make sure the directory
> they've got their solarconfig.xml is in the classpath when they start the
> server.

I'd agree that once a user is using a custom plugin, they are advanced
enough they can handle the classpath issues themselves.

> Once the solrconfig is loaded -- a lot becomes easier ... the index
> directory and the schema.xml path can be specified there, as absolute
> paths or relative if that's what the client wants to use.

The index dir may already be specified as relative or absolute in
solarconfig.xml.  I don't have anything like that for the other config
files like the schema though.  I'm inclined to punt that until someone
actually needs solarconfig.xml and schema.xml in different places.

> That said ... I can't believe other webapp applications don't have this
> problem too ... how do most apps distributed as a WAR deal with their
> configuration in a server agnostic way?

Our closest cousin, nutch, uses the CWD to find it's segments at least.

-Yonik