I asked a question similar to this back in http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200709.mbox/[EMAIL PROTECTED] and didn't really find anyone who was doing this. What I wound up doing was adding a variable to the context.xml file called contextRelativeHome:
<env-entry> <env-entry-name>solr/contextRelativeHome</env-entry-name> <env-entry-type>java.lang.Boolean</env-entry-type> <env-entry-value>true</env-entry-value> </env-entry> Which causes the SolrResourceLoader to prepend the context directory to the solr/home variable (the context directory is identified in the SolrDispatchFilter and stored in the global Config). This way, I can have a multiple instances of Solr up and running with the exact same configuration, and their indices contained wholly within their deployment directories. So since this is a fresh thread, does this seem like a bad way to do it? It would be much easier if I could put context variables directly into the existing solr/home variable, for sure. Anthony -----Original Message----- From: Chris Hostetter [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 11, 2007 1:09 PM To: solr-user@lucene.apache.org Subject: Re: Two Solr Webapps, one folder for the index data? : I actually have a patch for solr config parser which allows you to use : context environment variables in the solrconfig.xml : I generally use it for development when I'm working with multiple : instances and different data dirs. I'll add it to jira today if you : want it. yes please! ... Solr already has system property variable replacement in solrconfig.xml, and we discussed a while back (on solr-dev i think) adding code to automatily create system properties on startup for any solr/* JNDI variables set so the same variable subst code could be reused ... but i don't think anyone ever opened an issue or created a patch for it. -Hoss
