Thanks Erick, that mirrors my thoughts exactly. If core.properties had
property expansion it would work for this, but I agree with not
supporting that for the complexities it introduces, and I'm not sure
it's the right way to solve it anyway. So, it doesn't really handle my
problem.
I think because the properties file I want to load is not actually
related to any core, it makes it easier to solve. So if solr.xml is no
longer rewritten then it seems like a global properties file could
safely be specified there using property expansion. Or maybe there is
some way to write some code that could get executed before schema and
solrconfig are parsed, although I'm not sure how that would work given
how you need solrconfig to load the libraries and define plugins.
Ryan
On 08/20/2014 01:07 PM, Erick Erickson wrote:
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
