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
>
>
