[jira] Commented: (SOLR-414) Coherent plugin initialization strategy

["Henri Biestro (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548304 ] 

Henri Biestro commented on SOLR-414:
------------------------------------

Seems to me that relaxing by class will end up being very user-unfriendly if it is not easy to add a class to the list of "really" aware classes (would even seem counter-effective).
There are 2 approaches, one is to be explicit, the other is to relax the whole constraint and let the interface trigger the behavior.
On the explicit side, one solution could be an attribute in the schema (or alternatively a static block to register the class).
On the implicit side, relaxing by "interface" (versus per concrete instance) is almost a full-loop on the subject with the twist that we succeeded preserving the init signatures.
We might then want to reintroduce the solr-399 dependency graph feature since we are (back to) using Solr core objects before the core is fully initialized.
Thoughts ?

> Coherent plugin initialization strategy
> ---------------------------------------
>
>                 Key: SOLR-414
>                 URL: https://issues.apache.org/jira/browse/SOLR-414
>             Project: Solr
>          Issue Type: Improvement
>    Affects Versions: 1.3
>            Reporter: Ryan McKinley
>            Assignee: Ryan McKinley
>             Fix For: 1.3
>
>         Attachments: SOLR-414-Initialization.patch, SOLR-414-Initialization.patch, SOLR-414-Initialization.patch, SOLR-414-Initialization.patch, SOLR-414-Initialization.patch
>
>
> We currently load many plugins with a Map or NamedList -- since SOLR-215, the current core is not available through SolrCore.getSolrCore() and may need to be used for initialization.
> Ideally, we could change the init() methods from:
> {panel}void init( final Map<String,String> args );{panel}
> to
> {panel}void init( final SolrCore core, final Map<String,String> args );{panel}
> Without breaking existing APIs, this change is difficult (some ugly options exist).  This patch offers a solution to keep existing 1.2 APIs, and allow access to the SolrConfig and SolrCore though ThreadLocal.  This should be removed in a future release.
> {panel}
>   DeprecatedPluginUtils.getCurrentCore();
>   DeprecatedPluginUtils.getCurrentConfig();
> {panel}
> This patch removes the SolrConfig.Initalizable that was introduced in SOLR-215.
> For background, see:
> http://www.nabble.com/Initializing---break-init%28%29-API-compatibility--tf4808463.html
> See also: SOLR-260, SOLR-215,  SOLR-399

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