[
https://issues.apache.org/jira/browse/SOLR-6548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14143668#comment-14143668
]
Brian commented on SOLR-6548:
-----------------------------
I guess what I specifically wanted to do is already possible, though maybe it
is overly complex. I could declare plugins of a custom type as child nodes in
the xml definition for a known type (e.g., request handler), so long as the
classes implement SolrInfoMBean. This is following what the highlighting
component does - it has a number of different "fragmenter" types each with a
different class, and these get loaded as children PluginInfo of the
highlighting component PluginInfo. So during SolrCoreAware inform they can be
read and instantiated from the passed-in PluginInfo, e.g.,
info.getChildren("highlighting");
I guess maybe one downside is the child plug-ins couldn't easily be shared
between different handlers.
I will close this issue - if needed a new one could always be opened.
> 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]
