Thanks Erick, I tested that does work, and provide a solution to my
problem! So property expansion does work in core.properties, I did not
know that, and I got the impression from Chris' comment that that would
open up a can of worms when it comes to persisting core.properties. I
guess while the can's open, I'll eat up.
Just for fun I tried property expansion in my referenced subproperties
file and it didn't work, which is fine for me.
Ryan
On 08/20/2014 04:11 PM, Erick Erickson wrote:
OK, not quite sure if this would work, but....
In each core.properties file, put in a line similar to what Chris suggested:
properties=${env}/custom.properties
You might be able to now define your sys var like
-Drelative_or_absolute_path_to_dev_custom.proerties file.
or
-Drelative_or_absolute_path_to_prod_custom.proerties file.
on Solr startup. Then in the custom.properties file you have whatever
you need to define to make the prod/dev distinction you need.
WARNING: I'm not entirely sure that relative pathing works here, which
just means I haven't tried it.
Best,
Erick
On Wed, Aug 20, 2014 at 3:11 PM, Ryan Josal <ry...@pointinside.com> wrote:
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
