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