[
https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741414#action_12741414
]
Hoss Man commented on SOLR-1335:
--------------------------------
Noble: i'm really confused about a few things...
1) skimming the patch to CoreContainer it looks like "solrconfig.properties" is
intented to be a new hardcoded magic filename ... but with the push towards
solr.xml being the one and only magic hardcoded filename wouldn't it make more
sense to people specify a properties file name (or names) there? (just like
they can specify individual properties)
2) i don't really understand the way the test code is structured ...
TestSolrCoreProperties extends TestCase, and contains a private inner class
SolrInstance extends AbstractSolrTestCase (extends TestCase,) ... huh?
SolrInstance's only value add on top of AbstractSolrTestCaseseems to be the
creations of a new "solrcore.properties" file with some values in it ... but
why not just commit an example "solrcore.properties" file directly into the
test directory?
What's the need for the inner test class? (that file creation could be in the
outer setUp() method just as easily) and how does the test actaully verify that
a property was set correctly? (the only properties i can see used in
solrconfig-solcoreproperties.xml are in garbage xml tags: tag1 & tag2 which
aren't going to affect any behavior)
(As a general rule: anytime i see System.setProperty i get worried ... those
are going to affect the whole VM, not just this test, which could cause all
sorts of confusion for other people (or other tests))
> 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.
