lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-1335) load core properties from a properties file
Date Tue, 18 Aug 2009 18:22:14 GMT

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


Mime
View raw message