lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henrib <hbies...@gmail.com>
Subject Re: SolrConfig.Initializable
Date Sun, 21 Oct 2007 14:08:31 GMT


I dont see any wrong or bad reason for the change since I believe we never
share an object created by one core (and dependant on it) with another core
- and we probably shouldn't.

At some point, solr-215 was passing the SolrCore to dynamically created
objects instead of the SolrConfig in init. The remnant shows in
SolrCore.createInstance.
The SolrConfig.Initializable was introduced to reduce the change scope of
the patch.

Any reason to (re)introduce SolrCore.Initializable instead of constructors
that can take a SolrCore as a parameter?

Henrib


hossman wrote:
> 
> 
> The SolrConfig.Initializable interface was introduced as part of SOLR-215 
> to give Token(izer|Filter)Factories access to the SolrConfig (i believe 
> just because StopFilter and SynonymFilter needed getLines)
> 
> I can't help but wonder if it would make more sense to replace this with 
> something like "SolrCore.Initializable" ... you can get a SolrConfig from 
> a SolrCore, but you can't get a SolrCore from a SolrConfig.
> 
> This would be a big help for things like SOLR-319.
> 
> Is there any particular reason why it would be bad to pass the SolrCore to 
> the init method instead of the SolrConfig?
> 
> 
> 
> -Hoss
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/SolrConfig.Initializable-tf4665036.html#a13329383
Sent from the Solr - Dev mailing list archive at Nabble.com.


Mime
View raw message