[
https://issues.apache.org/jira/browse/SOLR-6548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14143351#comment-14143351
]
Hoss Man commented on SOLR-6548:
--------------------------------
I'm missing something fundemental to your suggestion here ... you have
configuration to tell you what types of plugin configurations are supported?
... and then what? loadPluginInfo creates a PluginInfo object corrisponding
and what happens next? ... what piece of code does something with those
PluginInfo objects?
i don't understand how you can have user defined _types_ of plugins w/o some
code in solr knowing aout those types of plugins and invoking them.
> 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]
