lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Josal <>
Subject Re: Dynamically loaded file
Date Thu, 21 Aug 2014 17:34:57 GMT
Thanks Erick, I tested that does work, and provide a solution to my 
problem!  So property expansion does work in, 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  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.


On 08/20/2014 04:11 PM, Erick Erickson wrote:
> OK, not quite sure if this would work, but....
> In each file, put in a line similar to what Chris suggested:
> properties=${env}/
> 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 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 <> wrote:
>> Thanks Erick, that mirrors my thoughts exactly.  If 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 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.
>>> Best,
>>> Erick
>>> 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