lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Biestro (JIRA)" <j...@apache.org>
Subject [jira] Updated: (SOLR-399) SolrConfig.Initializable: allow configurable class instances to depend on the SolrCore instance
Date Fri, 26 Oct 2007 17:01:50 GMT

     [ https://issues.apache.org/jira/browse/SOLR-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Henri Biestro updated SOLR-399:
-------------------------------

    Attachment: solr-399.patch

The patch is not yet functional (tests fail).

> SolrConfig.Initializable: allow configurable class instances to depend on the SolrCore
instance
> -----------------------------------------------------------------------------------------------
>
>                 Key: SOLR-399
>                 URL: https://issues.apache.org/jira/browse/SOLR-399
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Henri Biestro
>            Priority: Minor
>             Fix For: 1.3
>
>         Attachments: solr-399.patch
>
>
> WHAT:
> This patch introduces initialization behaviors for instances of configurable classes.
> WHY:
> Introduced through solr-215, SolrConfig.Initializable allows some classes (Tokenizer,
Filter) to get access to the SolrConfig at initialization time.
> It would be convenient to extend this so that instances of configurable classes could
access objects known by the core - and thus the schema . 
> see http://www.nabble.com/SolrConfig.Initializable-tf4665036.html
> HOW:
> SolrConfig is extended to declare some new initialization dedicated interfaces (Initializable,
InitializablePlugin, InitializableBy) that classes wishing to benefit from the initialization
behaviors need to implement. SolrCore.Initializable interface is also introduced for the same
purpose. All those interfaces require the implementation of some 'init' method.
> It is guaranteed that:
> 1/ SolrConfig.Initializable*.init is called before SolrCore.Initializable.init
> 2/ SolrCore.Initializable.init is guaranteed to be called only once when it is successful
at core initialization time.
> When the core is being initialized, all instances that go through SolrConfig.initInstance
that are SolrCore.Initializable are queued into an initialization list that guarantees uniqueness
(aka they are only queued once).
> At the end of core initialization, the solrConfig.init(core) is called; this triggers
the call to SolrCore.Initializable.init(core) for each queued instances. That method must
be implemented to return 'true' if the initialization has been performed, 'false' if it must
be re-evaluated. This allows one instance to depend on another initialization (a tokenizer
could require a fieldType).
> Solrconfig will loop around the queue while it can successfully initialize instances
or new ones are posted; if the loop can not reduce the number of instances expecting initialization,
it is considered an error (and this will avoid potentially cyclic dependencies).
> After the core has been initialized, the SolrConfig will automatically post instance
to the SolrCore queue & empty it right away with the same behavior.
> Note that after the core has been initiallized, the SolrConfig is bound to that core;
reusing such a bound SolrConfig for another core will generate an exception.
> USAGE:
> Any class that implements one of SolrConfig.Init* interface implements some 'init' method
that will be called through SolrConfig.
> The sequence of call is:
> SolrConfig.Initializable instance = solrConfig.newInstance("name.of.class");
> ...
> solrConfig.initInstance(instance, args);

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message