[
https://issues.apache.org/jira/browse/SOLR-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503673
]
Hoss Man commented on SOLR-260:
-------------------------------
Ryan: FYI but there is currently no patch attached to this issue.
looking ta the way PluginLoader is used in the latest SOLR-225 patch, i wonder
if some of this stuff could be simplified more by adding two new super
interfaces to many of the things that can currently be specified as plugins
(you alluded to this in an old comment in SOLR-225 that i remember seeing when
skimming my email a while back, but never really got a chance to comment on).
Assuming we have two interfaces like this...
public interface MapInitializedPlugin {
init( Map<String,String> args);
}
public interface NamedListInitializedPlugin {
init( NamedList args );
}
...then the PluginLoader concept can be much simpler can't it? something
like...
public abstract class AbstractPluginLoader<T> {
protected T createInstance(String pluginClassName) {
Class clazz = Config.findClass( pluginClassName, DEFAULT_PACAKGES);
return (T) clazz.newInstance(); // :TODO: do some error check that clazz
extends T
}
public class MapPluginLoader<T extends MapInitializedPlugin> extends
AbstractPluginLoader<T> {
protected T createInstance(String pluginClassName, Map<String,String> args)
{ createInstance( pluginClassName); }
public T getInstance(String pluginClassName, Map<String,String> args) {
T plugin = createInstance(pluginClassName);
plugin.init(args);
return plugin;
}
}
public class NamedListPluginLoader<T extends NamedListInitializedPlugin>
extends AbstractPluginLoader<T> {
protected T createInstance(String pluginClassName, NamedList args) {
createInstance( pluginClassName); }
public T getInstance(String pluginClassName, NamedList args) {
T plugin = createInstance(pluginClassName);
plugin.init(args);
return plugin;
}
}
...similar batch processing methods to the ones you already have (for dealing
with DOM Nodes) can also be added, but the key is that you can say things
like...
SolrRequestHandler r = (new
NamedLIstPluginLoader<SolrRequestHandler>()).getInstance(concreteImplName);
...instead of each usage needing to provide an impl for the PluginLoader.init
method (and the methods don't all have the double usage of NamedList and
Map<String,String> args that might confuse people since one of them is always
ignored).
NOTE: I'm not sure why you have your PluginLoader.create method abstract ... it
seems like the common case is common enough that we can provide a default impl.
> reusable PluginLoader -- helper class to load plugins
> -----------------------------------------------------
>
> Key: SOLR-260
> URL: https://issues.apache.org/jira/browse/SOLR-260
> Project: Solr
> Issue Type: New Feature
> Reporter: Ryan McKinley
>
> As we talk about adding more configuration (Handlers, Highlighting,
> Components, etc) we should standardize the format and share the loading and
> initialization code.
> This patch extracts the common stuff from SOLR-225 and makes it work with the
> RequestHandler framework.
> This is an abstract base class -- each implementation needs to take care of
> actually creating and initializing the instances:
> abstract class PluginLoader<T>
> {
> abstract public T create( String className, NamedList args,
> Map<String,String> params );
>
> abstract public void init( T plugin, NamedList args, Map<String,String>
> params );
>
> public Map<String,T> load( NodeList nodes )
> {
> ...
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
