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 Wed, 14 Nov 2007 10:01:12 GMT


ryantxu wrote:
> 
> but I fear we are turning the initialization into a jumbled spaghetti of
> interface looparounds, callbacks and pending lists 
> of soon-to-be-initialized stuff.
> (not just this patch - but the combination of requirements we have had for
> all the plugin stuff)
> 
I agree this is "messy"; a common/simple void init(SolrCore core, ...) would
be much better.
I'm no fan of a thread local solution and I believe we can smoothly
transition the API the same way we did when we introduced the
SolrConfig.Initializable (deprecation plus default implementation).


ryantxu wrote:
> 
> One key design choice is if we can pass a not fully initialized SolrCore
> to an init method.
> 
I think we should pass the core even if not fully initialized since there
are already ways today to access the core during init phase anyway
(SolrCore.getSolrCore).
We should document the config/schema/core initialization order so users know
what they can access from a core/schema/config during init (before the core
really starts).
Plus, if we are able to keep the solr-399 feature, besides cyclic or
unsolvable dependencies, the initialization order might just adapt.


ryantxu wrote:
> 
> The solrconfig stuff definitely needs access to the current core. 
> I'm not sure if schema related things need access (it currently does not). 
> Both cases need access to the 'config' in order to access the ClassLoader.
> 
One of the starting point was to allow a tokenizer to use a fieldType;
schema related objects thus need access to others and passing the core would
allow that (getSchema).
Just the same way the core let's us access the solrconfig (getSolrConfig).


ryantxu wrote:
> 
> alternatively, we have to do something like SOLR-399 that queues up
> everything until the core is completely initialized.
> 
I guess solr-399 algorithm can be adapted & kept; if nothing prevents
initialization do it, otherwise postpone it.
Instead of a boolean init(...), we might try to use an exception to indicate
initialization is to be postponed & retried (considering this case as an
exceptional but recoverable workflow).
And we could capture the init continuation in the exception (ala
PluginInitInfo for instance).
Let me know if I should investigate feasibility more thoroughly.
-- 
View this message in context: http://www.nabble.com/SolrConfig.Initializable-tf4665036.html#a13743457
Sent from the Solr - Dev mailing list archive at Nabble.com.


Mime
View raw message