Re: solr.xml isn't loaded from classpath?

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

: It seems like when "solr home" is absent, Solr makes an attempt to look 
: a few other places to load its configuration.  It will try to look for 
: solrconfig.xml on the classpath as well.  It doesn't seem like it makes 
: any attempt to find solr.xml though.  Why is that?  Read below for the 
: larger narrative...

First off: there is always a "solr home", even if you don't want to use 
it it has to exist, either explicitly declared, or implicitly it uses 
./solr/ in the CWD -- even if that directory doesn't exist, as a last 
resort that directory is used.

Second: the ability to load files out of the classpath was always been 
something of a missfeature.  It existed in the early versions of Solr 
largely as a fluke, and it has caused some problems in the past.  my 
personal pet peeve is that it really makes it hard to provide good error 
messages when people have typos in paths/filenames; but more recently (as 
i understand it) it is causing problems with the SolrCloud efforts, so 
classpath loading of config files may not definitley be supported in Solr 
4x.

Third: the very specific and concrete reason why solr.xml can't be loaded 
from the classpath (and never has been) is that from day one that solr.xml 
(and multicore support) was added, solr supported CoreAdmin functionality 
which allows you to add SolrCores at runtime and persist the changes to 
solr.xml -- which means it can't be something read from the classpath, it 
has to be something with a real concrete path thta solr can write to.

In theory, the code could be teased apart to make all of the persistence 
opional if and only if the file isn't loaded from the classpath, but as i 
mentioned: the classpath loading in general may not actually be 
supported long term.

: Having this configuration discovery makes things really convenient for 
: creating custom Solr web applications where you can throw all of Solr's 
: config in your resources, create a war, deploy it to Tomcat and it 
: happily loads.  No setting of environment variables or setup required.  

	...

: And when you try to run this, Solr can't find what it needs to start up.  
: To fix this, we manually deployed the configuration on the web server 
: and set the solr/home environment variable on the web app's config 
: within Tomcat.  Not ideal and it makes automation awkward.
: 
: Ultimately, I want a completely packaged war for a multicore instance I 
: can drop anywhere without additional setup.  Is this possible?  Am I 
: approaching this wrong?

Well, my first question would be: where are you keeping the index?

Assuming you don't care about persistence of data, and are okay with your 
data vanishing everytime the webapp is reloaded (and that's all i can 
imagine you can do if you don't have any physical files on disk)

My suggestion would be to have your custom war use a temp dir to create a 
solr home, and expand all of your config files into that (and use it for 
keeping the data)

Alternately: Assuming you start using 3x, you can keep doing what you've 
been doing with the single core approach, but have your own init code in 
your war (that runs after SOlrDispatchFilter.init()) use the CoreAdmin 
commands to dynamicly register the various SolrCores you want (on the 3x 
branch, even when CoreContainer can't find a solr.xml it uses a hardcoded 
default that initializes one core configured to be the "default", and 
setups the URL /admin/cores for doing non-persistent Core administration)


-Hoss