[
https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544592
]
Hoss Man 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?
In theory "ResourceLoader" can be a very constrained interface for the plugins
themselves that has no Solr dependencies...
public interface ResourceLoader {
/* a way to instantiate objects using an appropriate classloader */
public Object newInstance(String classname, String... subpackages);
/* a way to open config files, may check multiple directories in a set
order */
public InputStream openResource(String name);
// ... getLines probably makes sense too.
}
...and Solr has a concrete SolrResourceLoader class that knows about the
instanceDir, config dir, default packages for plugins, etc....
> 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.
