lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henrib <>
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
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:
Sent from the Solr - Dev mailing list archive at

View raw message