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