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
problem?
I don't think we want to make the name of core.properties 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 core.properties
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
core.properties to point to an additional external file that should
also be loaded ... if variable substitution was in play when parsing
core.properties then you could have something like
properties=custom.${env}.properties in core.properties ... but
introducing variable substitution into thecore.properties (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.
Best,
Erick
On Wed, Aug 20, 2014 at 11:36 AM, Ryan Josal <ry...@pointinside.com> 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 dev.properties file and a prod.properties 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
