lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-6548) Enable custom plugin types via configuration
Date Mon, 22 Sep 2014 19:35:33 GMT

    [ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message