You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "Noble Paul (JIRA)" <ji...@apache.org> on 2009/08/05 08:03:14 UTC
[jira] Created: (SOLR-1335) load core properties from a properties
file
load core properties from a properties file
-------------------------------------------
Key: SOLR-1335
URL: https://issues.apache.org/jira/browse/SOLR-1335
Project: Solr
Issue Type: New Feature
Reporter: Noble Paul
There are few ways of loading properties in runtime,
# using env property using in the command line
# if you use a multicore drop it in the solr.xml
if not the only way is to or keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
In our case we have four different configurations for the same deployment of replication
# main master
# slaves of main master
# repeater
#slaves of repeater
It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr
I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by Noble Paul നോബിള് नोब्ळ् <no...@corp.aol.com>.
then it is the same
On Thu, Sep 24, 2009 at 1:34 PM, Artem Russakovskii (JIRA)
<ji...@apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759059#action_12759059 ]
>
> Artem Russakovskii commented on SOLR-1335:
> ------------------------------------------
>
> We're using single core.
>
>> load core properties from a properties file
>> -------------------------------------------
>>
>> Key: SOLR-1335
>> URL: https://issues.apache.org/jira/browse/SOLR-1335
>> Project: Solr
>> Issue Type: New Feature
>> Reporter: Noble Paul
>> Assignee: Noble Paul
>> Fix For: 1.4
>>
>> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>>
>>
>> There are few ways of loading properties in runtime,
>> # using env property using in the command line
>> # if you use a multicore drop it in the solr.xml
>> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
>> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
>> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
>> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
--
-----------------------------------------------------
Noble Paul | Principal Engineer| AOL | http://aol.com
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Otis Gospodnetic (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743310#action_12743310 ]
Otis Gospodnetic commented on SOLR-1335:
----------------------------------------
Mind including an example properties file, so we can see what's in it?
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1335) load core properties from a properties
file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Noble Paul resolved SOLR-1335.
------------------------------
Resolution: Fixed
committed : r807914
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1335) load core properties from a properties
file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Noble Paul updated SOLR-1335:
-----------------------------
Description:
There are few ways of loading properties in runtime,
# using env property using in the command line
# if you use a multicore drop it in the solr.xml
if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml. The configurations are...
# main master
# slaves of main master
# repeater
# slaves of repeater
It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr.
I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
was:
There are few ways of loading properties in runtime,
# using env property using in the command line
# if you use a multicore drop it in the solr.xml
if not the only way is to or keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml
# main master
# slaves of main master
# repeater
# slaves of repeater
It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr.
I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml. The configurations are...
> # main master
> # slaves of main master
> # repeater
> # slaves of repeater
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr.
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747223#action_12747223 ]
Noble Paul commented on SOLR-1335:
----------------------------------
both schema and config are specified as attributes. That is why I kept it as attribute. DO we really need to support multiple ?
if necessary we can "overload" the existing "property" tag instead of introducing one
{code:xml}
<core name="foo">
<property file="conf/foo.properties"/>
</core>
{code}
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-1335) load core properties from
a properties file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12745028#action_12745028 ]
Noble Paul edited comment on SOLR-1335 at 8/19/09 5:19 AM:
-----------------------------------------------------------
bq.Error prone? I don't buy that. It's the same as setting a name in a .properties file - no more error prone than that.
these properties files are separately shipped and the developer decides what are the properties.
bq.Global properties - yes, but you can "namespace" them... -Dcore1name.master=false -Dcore2name.master=true kinda stuff.
is this clean?
The system properties are available across the JVM . Why do you want a system wide property for something that is only used in solrconfig/schema? There is a chance of it conflicting with other system properties too.
I do not see the reason against the properties. It is more like your ant script loading external properties from a properties file. Nobody is mandating the use of it . If one needs to clean up the deployment he is welcome to use it.
was (Author: noble.paul):
bq.Error prone? I don't buy that. It's the same as setting a name in a .properties file - no more error prone than that.
these properties files are separately shipped and the developer decides what are the properties.
bq.Global properties - yes, but you can "namespace" them... -Dcore1name.master=false -Dcore2name.master=true kinda stuff.
is this clean?
I do not see the reason against the properties. It is more like your ant script loading external properties from a properties file. Nobody is mandating the use of it . If one needs to clean up the deployment he is welcome to use it.
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1335) load core properties from a properties
file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Noble Paul updated SOLR-1335:
-----------------------------
Attachment: SOLR-1335.patch
* The properties filename is configurable from solr.xml on a per-core basis
* The testcase is cleaned up
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12745007#action_12745007 ]
Noble Paul commented on SOLR-1335:
----------------------------------
bq.Noble - why aren't system properties viable for this?
* Setting system properties is error prone. If we have a few dozen properties setting -D for each property is hard. The startup scripts are maintained by operations whereas this properties file should be delivered by the developers. This is more about a separation of concern
* System properties are global properties. we should not corrupt that namespace
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744882#action_12744882 ]
Noble Paul commented on SOLR-1335:
----------------------------------
bq.I also contest your claim that they are alwasy hardcoded for single cores ... we've been making definite progress down a path of encouraging people to use solr.xml even for single core setups, as you say..
Are we going to do thiat in 1.4 i.e solr.xml for single cores? But this properties file is a critical feature for our ops to deploy solr with replication feature. (The master server is only known at deploy time). currently we are shipping four different solrconfig.xml files
I am not really worried about the specifics of how we implement this. My requirements are pretty simple
* A core should be able to load properties from a properties file (any file name, any loaction is OK)
* There should be one sensible default for that file name and location , just the way we have for schema and solrconfig
What is your preference of doing this?
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1335) load core properties from a properties
file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Noble Paul updated SOLR-1335:
-----------------------------
Attachment: (was: SOLR-1335.patch)
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740878#action_12740878 ]
Noble Paul commented on SOLR-1335:
----------------------------------
hi everyone, If there are no objections I plan to commit this as soon as I write a testcase. Please comment, because this is a very visible change
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741694#action_12741694 ]
Noble Paul commented on SOLR-1335:
----------------------------------
Hoss, thanks for the comments
bq."solrconfig.properties" is intented to be a new hardcoded magic filename .
For a single-core the filenames are always hardcoded like solrconfig.xml and schema.xml. solrconfig.xml filename can be overridden from web.xml, but that is only if I modify the solr.war which I believe is not really used and it is "hacking solr".
bq.but with the push towards solr.xml being the one and only magic hardcoded filename
This is a good idea. But most of the users use single core deployments and the goodies that come with solr.xml is not available for them. So it is not much helpful . I wish the single core also becomes a multicore with one core and all these confusions can go away.
We can of course extend this feature by adding a property to the core tag as <core properties="conf/props.properties"> in solr.xml . Do we really need to do it now because the properties file itself is optional and adding that to solr.xml can add to more clutter for a feature that is not widely used . Even if we add it later it is going to be backward compatible.
For the testcase , I just copied it from another w/o giving it much of a thought. The inner class can be avoided
bq.anytime i see System.setProperty i get worried
do we really have a choice here? Solr needs solr.solr.home to be set as a system property and all testcases follow this pattern
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Erik Hatcher (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12745602#action_12745602 ]
Erik Hatcher commented on SOLR-1335:
------------------------------------
Along the same lines as making master/searcher determination through properties, it would be nice to be able to conditionally enable/disable, say, /update handler by some deploy-time switch. Noble - does it make sense to consider this type of use here?
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Erik Hatcher (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747338#action_12747338 ]
Erik Hatcher commented on SOLR-1335:
------------------------------------
Keep it as an attribute. If/when we need, we can simply make it support a comma-separated list of files.
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747339#action_12747339 ]
Noble Paul commented on SOLR-1335:
----------------------------------
bq.Keep it as an attribute. If/when we need, we can simply make it support a comma-separated list of files.
+1
Multiple properties is an uncommon case . As you mentioned we should be able to support it using a comma-separated values
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12745028#action_12745028 ]
Noble Paul commented on SOLR-1335:
----------------------------------
bq.Error prone? I don't buy that. It's the same as setting a name in a .properties file - no more error prone than that.
these properties files are separately shipped and the developer decides what are the properties.
bq.Global properties - yes, but you can "namespace" them... -Dcore1name.master=false -Dcore2name.master=true kinda stuff.
is this clean?
I do not see the reason against the properties. It is more like your ant script loading external properties from a properties file. Nobody is mandating the use of it . If one needs to clean up the deployment he is welcome to use it.
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Artem Russakovskii (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758985#action_12758985 ]
Artem Russakovskii commented on SOLR-1335:
------------------------------------------
Paul, thank you. How funny - I was using nightly build from 8/25/09 and looks like the final commit was made on 8/26/09. Doh!
So I verified $solr_home/conf/solrcore.properties as working, and it's good enough for us, but it'd be ideal if this location can be specified in solrconfig.xml, for example to be set to '$solr_home/..'. However,
a) I'm not sure this is supported right now
b) I think we came to a conclusion in another ticket that there's no value $solr_home that one can refer to from within solrconfig.xml (http://www.nabble.com/Solr,-JNDI-config,-dataDir,-and-solr-home-problem-td25286277.html and SOLR-1414), although it looks like you may have fixed it - is it accessible by ${solr.core.instanceDir} now?
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Lance Norskog (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12745680#action_12745680 ]
Lance Norskog commented on SOLR-1335:
-------------------------------------
About use cases for this feature:
I would like to use this along with my strange baby, [SOLR-1354|http://issues.apache.org/jira/browse/SOLR-1354]. It would allow me to push all parameters for an RSS/ATOM feed into a separate configuration file. This way, to add an rss feed to a Solr instance requires editing a properties file and nothing else. (The larger goal is here to make it as easy as possible to make solr useful out of the box.)
Another place where properties files would be very useful is in DIH scripts. When we want to load multiple shards from the same data source, we need different code for each shard. It would be great to have one master DIH file and a different properties file for each shard. Each properties file has a unique value to define the records for that shard.
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Erik Hatcher (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744994#action_12744994 ]
Erik Hatcher commented on SOLR-1335:
------------------------------------
Noble - why aren't system properties viable for this? The replication examples show master="${master}" constructs, allowing a system property to set master versus slave.
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Artem Russakovskii (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759059#action_12759059 ]
Artem Russakovskii commented on SOLR-1335:
------------------------------------------
We're using single core.
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Artem Russakovskii (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758511#action_12758511 ]
Artem Russakovskii commented on SOLR-1335:
------------------------------------------
So, can someone comment on whether the single core setup (solrconfig.xml) supports referencing a properties file now? I'm not using multicore, like this bug's author, and after reading through the comments here, I'm still unclear on the single core solution.
Ideally, solrxonfig.xml would contain a location of the properties file, which it would load prior to parsing everything else.
Thanks.
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1335) load core properties from a properties
file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Noble Paul updated SOLR-1335:
-----------------------------
Attachment: SOLR-1335.patch
with license headers. I plan to commit this soon
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743138#action_12743138 ]
Noble Paul commented on SOLR-1335:
----------------------------------
The current default name is set as solrcore.properties. Is there any other preference for the name?
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1335) load core properties from a properties
file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Noble Paul updated SOLR-1335:
-----------------------------
Attachment: SOLR-1335.patch
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758993#action_12758993 ]
Noble Paul commented on SOLR-1335:
----------------------------------
solr.home is not technically same as solr.core.instanceDir . it can be different in a multicore setup
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12745799#action_12745799 ]
Noble Paul commented on SOLR-1335:
----------------------------------
bq.would be nice to be able to conditionally enable/disable, say, /update handler by some deploy-time switch
it is not currently possible. I recommend adding an attribute to each of the plugins "enable as follows
{code:xml}
<requestHandler name="/upadate" enable="${update_enable:true}"/>
{code}
specifying the properties file in solrconfig is not a good option because the properties has to be loaded before loading solrconfig.xml so that the variables are replaced at load time of solrconfig
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741414#action_12741414 ]
Hoss Man commented on SOLR-1335:
--------------------------------
Noble: i'm really confused about a few things...
1) skimming the patch to CoreContainer it looks like "solrconfig.properties" is intented to be a new hardcoded magic filename ... but with the push towards solr.xml being the one and only magic hardcoded filename wouldn't it make more sense to people specify a properties file name (or names) there? (just like they can specify individual properties)
2) i don't really understand the way the test code is structured ... TestSolrCoreProperties extends TestCase, and contains a private inner class SolrInstance extends AbstractSolrTestCase (extends TestCase,) ... huh?
SolrInstance's only value add on top of AbstractSolrTestCaseseems to be the creations of a new "solrcore.properties" file with some values in it ... but why not just commit an example "solrcore.properties" file directly into the test directory?
What's the need for the inner test class? (that file creation could be in the outer setUp() method just as easily) and how does the test actaully verify that a property was set correctly? (the only properties i can see used in solrconfig-solcoreproperties.xml are in garbage xml tags: tag1 & tag2 which aren't going to affect any behavior)
(As a general rule: anytime i see System.setProperty i get worried ... those are going to affect the whole VM, not just this test, which could cause all sorts of confusion for other people (or other tests))
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758575#action_12758575 ]
Noble Paul commented on SOLR-1335:
----------------------------------
bq.can someone comment on whether the single core setup (solrconfig.xml) supports referencing a properties file now
yes, you can. The filename and location is fixed for single core. It should be $solr_home/conf/solrcore.properties
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Lance Norskog (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747078#action_12747078 ]
Lance Norskog commented on SOLR-1335:
-------------------------------------
For future mantainability, please change:
{code:xml}
<core name="foo" properties="conf/foo-core.properties" ... />
{code}
to:
{code:xml}
<core name="foo">
<properties>conf/foo-core.properties</properties>
</core>
{code}
This allows us to have multiple properties files later.
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Erik Hatcher (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12745022#action_12745022 ]
Erik Hatcher commented on SOLR-1335:
------------------------------------
Error prone? I don't buy that. It's the same as setting a name in a .properties file - no more error prone than that.
Startup scripts - these could delegate to a developer maintained subscript that set variables to be included in -D settings.
Global properties - yes, but you can "namespace" them... -Dcore1name.master=false -Dcore2name.master=true kinda stuff.
I'm not yet convinced the additional .properties feature is warranted.
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743538#action_12743538 ]
Noble Paul commented on SOLR-1335:
----------------------------------
There is nothing specific in the properties .The user can choose to put in anything which he he would wish to replace in solrconfig/schema
eg: solrcore.properties
{code}
/#this variable can be directly used in the replication section of solrconfig.xml
masterUrl=http://master_host:8080/solr/replication
disableMaster=true
{code}
This following is our usecase.
The developer who prepares the solrconfig.xml does not know about the host in which it is going to be deployed. So he should just use placeholders in the solrconfig and leave a properties file to the operations. The operations edit the properties file according to the deployment.
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744629#action_12744629 ]
Hoss Man commented on SOLR-1335:
--------------------------------
bq. For a single-core the filenames are always hardcoded like solrconfig.xml and schema.xml. solrconfig.xml filename can be overridden from web.xml,
...and they can be overridden in solr.xml -- that's my main points: you are adding a filewhose name is hardcoded and can't be changed under any circumstances. currently solr.xml is the _only_ field with those kinds of rules, because the solrconfig.xml and schema.xml filenames can be specified in solr.xml.
I also contest your claim that they are alwasy hardcoded for single cores ... we've been making definite progress down a path of encouraging people to use solr.xml even for single core setups, as you say...
bq. I wish the single core also becomes a multicore with one core and all these confusions can go away.
...i agree with you completley, but it's not going to happen overnight, and adding more hardcoded things like this is just a step backwards.
Frankly: i don't even thing there should be a default name for this new properties file, i think that if you want Solr to load properties from a file for you, you should be required to use solr.xml, and specify a filename there -- that would also give us the benefit of letting people specify multiple filenames (which is my other big concern about a single magic filename: there can be only one of them. for something like schema.xml or solrconfig.xml that's not the end of the world because merging multiple files doesn't even make much sense, but property files are extremly simple, and it should be just as easy to specify 37 of them as it is to specify 1.
bq. Do we really need to do it now because the properties file itself is optional and adding that to solr.xml can add to more clutter for a feature that is not widely used . Even if we add it later it is going to be backward compatible.
If it's something we know we're going to want to do, and it's going to keep the code simpler in the long run, we might as well do it right the first time. there's already too much confusion between the distinction between the solr home dir, and the solr instance dir when dealing with solr.xml ... having a new magic filename just convolutes matters (looking at the code: i can't immediately tell, is the property file expected to be in the instanceDir, or the solr home? ... what if i have both?
bq. do we really have a choice here? Solr needs solr.solr.home to be set as a system property and all testcases follow this pattern
There shouldn't be any need for a test to set the solr.solr.home system property ... the TestHarness already takes care of initializing the core with the appropriate home dir.
(if for some reason this features tickles a bit of core initialization that doesn't work properly with the TestHarness then we should fix the TestHarness ... it's probably out of date with some of the EmbeddedSolr best practices anyway)
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1335) load core properties from a properties
file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Noble Paul updated SOLR-1335:
-----------------------------
Description:
There are few ways of loading properties in runtime,
# using env property using in the command line
# if you use a multicore drop it in the solr.xml
if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
was:
There are few ways of loading properties in runtime,
# using env property using in the command line
# if you use a multicore drop it in the solr.xml
if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml. The configurations are...
# main master
# slaves of main master
# repeater
# slaves of repeater
It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr.
I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
Fix Version/s: 1.4
Assignee: Noble Paul
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Lance Norskog (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12745678#action_12745678 ]
Lance Norskog commented on SOLR-1335:
-------------------------------------
About the features for subsituting properties file:
I have run multiple Solr instances (servlets) in the same container. Yes, multicore is the better way, but we shoud not force the user to have only one Solr per Tomcat . So, we should not force only one properties file via System.properties.
I would ask that if a configuration file uses a properties file, that configuration file should have the ability to name its own properties file. For example, solrconfig.xml should have its own entry for adding properties files. But, if solrconfig.xml names a file the solr.xml should be able to override that file name. To do this, the properties files should be named.
In conf/query_server.properties:
{code}
fq.size=400
{code}
In foo/conf/solrconfig.xml:
{code:xml}
<properties name="query_server">conf/query_server.properties</properties>
{code}
Later in solrconfig.xml:
{code:xml}
<filterCache
class="solr.FastLRUCache"
size="${query_server.fq.size:512}"
initialSize="512"
autowarmCount="0"/>
{code}
Then solr.xml can override the query_servers properties file. In solr.xml:
{code:xml}
<core name="foo">
<properties name="query_server">${core}/conf/query_server_mini.properties</properties>
</core>
{code}
This just gets worse and worse :)
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1335) load core properties from a properties
file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Noble Paul updated SOLR-1335:
-----------------------------
Attachment: SOLR-1335.patch
with a testcase
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12746746#action_12746746 ]
Noble Paul commented on SOLR-1335:
----------------------------------
Please let me know if anyone wants to change anything about this feature before committing this
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1335) load core properties from a
properties file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12745373#action_12745373 ]
Noble Paul commented on SOLR-1335:
----------------------------------
bq.If it's something we know we're going to want to do, and it's going to keep the code simpler in the long run, we might as well do it right the first time.
I'll propose this. Anyway we are planing to move to a stage where we will use solr.xml for single core as well. So I shall add the configuration of the properties in the <core> tag as follows
{code:xml}
<core name="foo" properties="conf/foo-core.properties" ... />
{code}
For single core , let us fix a file name . So when we introduce solr.xml for single core it becomes automatically configurable
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch, SOLR-1335.patch, SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1335) load core properties from a properties
file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Noble Paul updated SOLR-1335:
-----------------------------
Description:
There are few ways of loading properties in runtime,
# using env property using in the command line
# if you use a multicore drop it in the solr.xml
if not the only way is to or keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml
# main master
# slaves of main master
# repeater
# slaves of repeater
It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr.
I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
was:
There are few ways of loading properties in runtime,
# using env property using in the command line
# if you use a multicore drop it in the solr.xml
if not the only way is to or keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
In our case we have four different configurations for the same deployment of replication
# main master
# slaves of main master
# repeater
#slaves of repeater
It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr
I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not the only way is to or keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml
> # main master
> # slaves of main master
> # repeater
> # slaves of repeater
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr.
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1335) load core properties from a properties
file
Posted by "Noble Paul (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Noble Paul updated SOLR-1335:
-----------------------------
Attachment: SOLR-1335.patch
> load core properties from a properties file
> -------------------------------------------
>
> Key: SOLR-1335
> URL: https://issues.apache.org/jira/browse/SOLR-1335
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1335.patch
>
>
> There are few ways of loading properties in runtime,
> # using env property using in the command line
> # if you use a multicore drop it in the solr.xml
> if not , the only way is to keep separate solrconfig.xml for each instance. #1 is error prone if the user fails to start with the correct system property.
> In our case we have four different configurations for the same deployment . And we have to disable replication of solrconfig.xml.
> It would be nice if I can distribute four properties file so that our ops can drop the right one and start Solr. Or it is possible for the operations to edit a properties file but it is risky to edit solrconfig.xml if he does not understand solr
> I propose a properties file in the instancedir as solrcore.properties . If present would be loaded and added as core specific properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.