lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <>
Subject Re: Dynamically loaded file
Date Wed, 20 Aug 2014 20:07:38 GMT
Hmmm, I was going to make a code change to do this, but Chris
Hostetter saved me from the madness that ensues. Here's his comment on
the JIRA that I did open (but then closed), does this handle your

I don't think we want to make the name of be variable
... that way leads to madness and confusion.

the request on the user list was about being able to dynamically load
a property file with diff values between dev & production like you
could do in the old style solr.xml – that doesn't mean
needs to have a configurable name, it just means there needs to be a
configurable way to load properties.

we already have a properties option which can be specified in to point to an additional external file that should
also be loaded ... if variable substitution was in play when parsing then you could have something like
properties=custom.${env}.properties in ... but
introducing variable substitution into (which solr
both reads & writes based on CoreAdmin calls) brings back the host of
complexities involved when we had persistence of solr.xml as a
feature, with the questions about persisting the original values with
variables in them, vs the values after evaluating variables.


On Wed, Aug 20, 2014 at 11:36 AM, Ryan Josal <> wrote:
> Hi all, I have a question about dynamically loading a core properties file
> with the new core discovery method of defining cores.  The concept is that I
> can have a file and a file, and specify which
> one to load with -Dsolr.env=dev.  This way I can have one file which
> specifies a bunch of runtime properties like external servers a plugin might
> use, etc.
> Previously I was able to do this in solr.xml because it can do system
> property substitution when defining which properties file to use for a core.
> Now I'm not sure how to do this with core discovery, since the core is
> discovered based on this file, and now the file needs to contain things that
> are specific to that core, like name, which previously were defined in the
> xml definition.
> Is there a way I can plugin some code that gets run before any schema or
> solrconfigs are parsed?  That way I could write a property loader that adds
> properties from ${solr.env}.properties to the JVM system properties.
> Thanks!
> Ryan

View raw message