lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Josal <ry...@pointinside.com>
Subject Re: Dynamically loaded core.properties 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 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 <ryanj@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 <ryanj@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
>>


Mime
View raw message