lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan McKinley (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-414) Coherent plugin initialization strategy
Date Wed, 21 Nov 2007 21:19:43 GMT

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

Ryan McKinley commented on SOLR-414:
------------------------------------

> 
> it hadn't occurred to be that ResourceLoader could be a super class of Config ... i was
assuming it would just be an object SolrConfig (or the SolrCore) held on to, and we'd deprecate
those methods in Config.  is there an advantage i'm not thinking of to having it be superclass?
> 

The only reason it is a super class is for easy API compatibility. Perhaps a better way is
to have an independent ResourceLoader and add @deprecated getters to Config.java:
  
@Deprecated
public String getConfigDir()
{
  return loader.getConfigDir()
}


> In theory "ResourceLoader" can be a very constrained interface for the plugins themselves
that has no Solr dependencies...
> 

I like that.  I'll put the 'ResourceLoader' class in o.a.s.util 

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


Mime
View raw message