Ryan:
A slight misunderstanding here: The idea of allowing different names
for the core.properties file was the "can of worms". Or at least a new
can of worms. Using the existing stuff is an existing can of worms
;)...
Under any circumstances the only time this would come in to play is if
you are changing the core definitions, things like creating them,
renaming them and all that kind of stuff. From your problem
description, it looks like you don't particularly change them once
created but if you create them via the admin API you might have to
copy the custom properties file.
Best,
Erick
On Thu, Aug 21, 2014 at 10:34 AM, Ryan Josal <ry...@pointinside.com> wrote:
> 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
>>>
>>>
>
