: the environment variable (env-entry) in web.xml to configure the solr/home is : relative to the web server's working directory. I find this unusual as all the : servlet paths are relative to the web applications directory (webapp context, : that is). So, I specified solr/home relative to the web app dir, as well, at : first.
the intention is not that the SOlr Home dir be configured inside the web.xml -- it is *possible* to specify the solr home dir in the web.xml as you describe, but that's relaly just a fallback for people who really, really, want to bake all of the information into the war. solr.war is an application -- when you run hte paplication you specify (at run time) some configuration information. Hardcoding that config information into the war file is akin to compile a C++ program with all of hte config options hardcoded -- you can do it, but it's not very generic, and requires a lot of hacking whenever you want to upgrade. : (In my case, I want to deliver the solr web application including a custom : entity processor, so that is why I want to include the solr war as part of my : release cycle. It is easier to deliver that to the system administration than : to provide them with partial packages they have to install into an already : installed war, imho.) you don't have to "install into an already installed war" to add custom plugins .. you just have to put the jar file for your custom plugins into a "lib" directory instead of your solr home dir. This is really no different then something like the Apache HTTPD server. there is the application (the binary httpd / solr.war) there is your configuration (httpd.conf / solr home dir) and there are custom modules you can choose to load (libmod_entityprocessor.so / your-entityprocessor.jar) -Hoss
