[
https://issues.apache.org/jira/browse/SOLR-6548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14143437#comment-14143437
]
Brian edited comment on SOLR-6548 at 9/22/14 5:14 PM:
------------------------------------------------------
A potential alternative that would require more change would be to genericize
the SolrCore plugin initialization, instead of having a separate registry and
corresponding look-up method for each type, make it so it was a registry for
all types of plugins that need to be instantiated, and have a common look-up
method.
was (Author: brian44):
A potential alternative that would require more change would be to genericize
the SolrCore plugin initialization, instead of having it a registry and
corresponding look-up method for each type, make it so it was a registry for
all types of plugins that need to be instantiated, and have a common look-up
method.
> Enable custom plugin types via configuration
> --------------------------------------------
>
> Key: SOLR-6548
> URL: https://issues.apache.org/jira/browse/SOLR-6548
> Project: Solr
> Issue Type: Improvement
> Reporter: Brian
> Priority: Minor
>
> I wanted to add a custom plugin type so that for a new request handler that
> uses different types of query generators it would be easy to add new query
> generators in the future through the plugin system, without having to touch
> the handler code. To do so I wanted to add a "queryGenerator" plugin type.
> As far as I can tell this is not possible without modifying the solr core
> code.
> All of the available plugin types and corresponding names are hard-coded in
> the SolrConfig constructor "public SolrConfig(SolrResourceLoader loader,
> String name, InputSource is)" like:
> {code}
> loadPluginInfo(SolrRequestHandler.class,"requestHandler",
> REQUIRE_NAME, REQUIRE_CLASS, MULTI_OK);
> loadPluginInfo(QParserPlugin.class,"queryParser",
> REQUIRE_NAME, REQUIRE_CLASS, MULTI_OK);
> loadPluginInfo(QueryResponseWriter.class,"queryResponseWriter",
> REQUIRE_NAME, REQUIRE_CLASS, MULTI_OK);
> loadPluginInfo(ValueSourceParser.class,"valueSourceParser",
> REQUIRE_NAME, REQUIRE_CLASS, MULTI_OK);
> {code}
> I propose adding these mappings to solrconfig.xml, or at least allow adding
> additional plugin type mappings there.
> That way it would be easy to add new plugin types in the future, and users
> could create their own custom plugin types as needed. Also if the default
> ones were solely defined in the list, they could then easily be overriden.
> At first glance it seems like the change to enable this could be relatively
> simple. Adding a new "plugin-types" entry to the Solr configuration xml that
> has "plugin-type" entries each with a "name" and "class" sub-entry.
> Then the constructor would read this list from the config and then call the
> loadPluginInfo(pluginTypeClass, pluginTypeName, ...) method on each entry.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
