[ 
https://issues.apache.org/jira/browse/SOLR-6548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian updated SOLR-6548:
------------------------
    Description: 
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 also 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 for each one 
call the  loadPluginInfo(pluginTypeClass, pluginTypeName, ...) method on each.



  was:
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:

<pre class="code-java">
    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);
</pre>

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 also 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 for each one 
call the  loadPluginInfo(pluginTypeClass, pluginTypeName, ...) method on each.




> 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 also 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 for each one 
> call the  loadPluginInfo(pluginTypeClass, pluginTypeName, ...) method on each.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to