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