lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan McKinley <ryan...@gmail.com>
Subject Re: SolrConfig.Initializable
Date Wed, 14 Nov 2007 02:41:07 GMT
Henrib wrote:
> Just pinging on the subject and the related solr-399 patch; I understand the
> priority for this is low, just seeking some comment to determine whether
> this is the expected track (and how low the priority is).
> 

I started working on adding configuration to the search components in 
SOLR-281.  This is a case where we need access to the core for 
initialization.

I checked out the SOLR-399 patch - it looks good considering all our 
discussion... 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 think we need to have a clear initialization strategy and make sure 
everything conforms to that before releasing 1.3.

Looking over our plugin space, we have two main categories:
1. stuff defined in schema.xml (fieldTypes fields ...)
2. stuff defined in solrconfig.xml (requestHandlers, processors, 
components, writers, ...)

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 key design choice is if we can pass a not fully initialized SolrCore 
to an init method.  alternatively, we have to do something like SOLR-399 
that queues up everything until the core is completely initialized.


Rather then jumble things up with more hooks, queues and callbacks, I 
vote we migrate the NamedList/Map/NodeInitializedPlugin from:
   void init( final NamedList args )
to:
   void init( final SolrCore core, final NamedList args )


I'm not sure what the best approach for the schema family is.  As is, 
IndexSchema can be fully initialized independent of SolrCore -- for 
consistency, it may be nice to use:
   void init( final SolrCore core, final Map<String,String> args )
rather then:
   void init(SolrConfig solrConfig, Map<String,String> args)
If fields/fieldTypes will never need access to the current SolrCore, it 
is fine to leave as is.

- - - -

Another possibility is to perhaps use ThreadLocal to register the 
current core/config while initializing.  That seems a bit dangerous as 
it would assume preconditions that are not required by the API.  But 
this would make it possible to pass things around and not break/migrate 
the existing API.


ryan



Mime
View raw message