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.
