Quantcast

solr.xml isn't loaded from classpath?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

solr.xml isn't loaded from classpath?

Nicholas Swarr-2
(may have double posted...apologies if it is)

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

The gory details:

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.  Something like this,

/someapp/src/main/resources
   |-solrconfig.xml
   |-schema.xml
   |-etc.

The same approach is outlined here:
http://netsuke.wordpress.com/2010/06/24/launching-solr-from-maven-for-rapid-development/

We're creating a multicore installation and have created a folder structure which no longer has a solrconfig.xml at the top level of the resources.

/someapp/src/main/resources
   |-solr.xml
   |-core1
      |-solrconfig.xml
      |-schema.xml
      |-etc.
   |-core2
      |-solrconfig.xml
      |-schema.xml
      |-etc.

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?



This e-mail message, and any attachments, is intended only for the use of the individual or entity identified in the alias address of this message and may contain information that is confidential, privileged and subject to legal restrictions and penalties regarding its unauthorized disclosure and use. Any unauthorized review, copying, disclosure, use or distribution is strictly prohibited. If you have received this e-mail message in error, please notify the sender immediately by reply e-mail and delete this message, and any attachments, from your system. Thank you.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Chris Hostetter-3

: 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
Loading...