[
https://issues.apache.org/jira/browse/SOLR-1335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744629#action_12744629
]
Hoss Man commented on SOLR-1335:
--------------------------------
bq. For a single-core the filenames are always hardcoded like solrconfig.xml
and schema.xml. solrconfig.xml filename can be overridden from web.xml,
...and they can be overridden in solr.xml -- that's my main points: you are
adding a filewhose name is hardcoded and can't be changed under any
circumstances. currently solr.xml is the _only_ field with those kinds of
rules, because the solrconfig.xml and schema.xml filenames can be specified in
solr.xml.
I also contest your claim that they are alwasy hardcoded for single cores ...
we've been making definite progress down a path of encouraging people to use
solr.xml even for single core setups, as you say...
bq. I wish the single core also becomes a multicore with one core and all these
confusions can go away.
...i agree with you completley, but it's not going to happen overnight, and
adding more hardcoded things like this is just a step backwards.
Frankly: i don't even thing there should be a default name for this new
properties file, i think that if you want Solr to load properties from a file
for you, you should be required to use solr.xml, and specify a filename there
-- that would also give us the benefit of letting people specify multiple
filenames (which is my other big concern about a single magic filename: there
can be only one of them. for something like schema.xml or solrconfig.xml
that's not the end of the world because merging multiple files doesn't even
make much sense, but property files are extremly simple, and it should be just
as easy to specify 37 of them as it is to specify 1.
bq. 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.
If it's something we know we're going to want to do, and it's going to keep the
code simpler in the long run, we might as well do it right the first time.
there's already too much confusion between the distinction between the solr
home dir, and the solr instance dir when dealing with solr.xml ... having a new
magic filename just convolutes matters (looking at the code: i can't
immediately tell, is the property file expected to be in the instanceDir, or
the solr home? ... what if i have both?
bq. 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
There shouldn't be any need for a test to set the solr.solr.home system
property ... the TestHarness already takes care of initializing the core with
the appropriate home dir.
(if for some reason this features tickles a bit of core initialization that
doesn't work properly with the TestHarness then we should fix the TestHarness
... it's probably out of date with some of the EmbeddedSolr best practices
anyway)
> 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.
