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