[SOLR-414] Coherent plugin initialization strategy

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.3
• Fix Version/s: 1.3
• Assignee: Ryan McKinley
• Reporter: Ryan McKinley
• Created: 18/Nov/07 19:57
• Updated: 29/May/13 18:47
• Resolved: 06/Dec/07 23:20

Description

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:

void init( final Map<String,String> args );

to

void init( final SolrCore core, final Map<String,String> args );

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.

DeprecatedPluginUtils.getCurrentCore();
DeprecatedPluginUtils.getCurrentConfig();

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

Issue Links

• incorporates: SOLR-180 Define multiple tokenizes in a fieldType
• is related to: SOLR-594 StopFilterFactory, SynonymFilterFactory and EnglishProterFilterFactory not backwards compatible because of inform
• is related to: SOLR-399 SolrConfig.Initializable: allow configurable class instances to depend on the SolrCore instance