lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noble Paul (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-1335) load core properties from a properties file
Date Sat, 15 Aug 2009 04:26:14 GMT

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


Mime
View raw message