Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-dev@lucene.apache.org
Message-ID: <26089029.1193418110561.JavaMail.jira@brutus>
Date: Fri, 26 Oct 2007 10:01:50 -0700 (PDT)
From: "Henri Biestro (JIRA)" <jira@apache.org>
To: solr-dev@lucene.apache.org
Subject: [jira] Updated: (SOLR-399) SolrConfig.Initializable: allow
 configurable class instances to depend on the SolrCore instance
In-Reply-To: <25949804.1193400591537.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ 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.