[
https://issues.apache.org/jira/browse/SOLR-6548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14143428#comment-14143428
]
Brian edited comment on SOLR-6548 at 9/22/14 5:05 PM:
------------------------------------------------------
I guess it may not be as simple as I thought at first glance.
As of right now with only that change, for new custom types, it seems like the
code for initializing them would have to go in the initialization code of the
component that uses them. I.e., it would be along the same lines as the code
used in SolrCore to initialize the different components, e.g., "initQParsers()"
in SolrCore gets all the plugin classes found in the SolrConfig having the
QParser type and instantiates each.
Here's one way it could work:
For my custom request handler that makes use of the custom plugin type, in a
SolrCoreAware inform method, it would get all the plugin classes defined in the
SolrConfig extending the QueryGenerator plugin type, and based on which are
specified in its parameters, it would instantiate an object of each
QueryGenerator class as needed. So the component that uses the custom plugin
type could be responsible for instantiating and using them (the code could live
there), which would still allow adding new types without any code changes to
that component itself.
I.e., say I wanted to add a new query generator type "topic_based_generator",
then I would define "topic_based_generator" with a particular QueryGenerator
class in solrconfig.xml with the class contained in a new jar I added to the
library directory, like we do for custom query parsers. The pluginInfo would
get loaded by the SolrConfig constructor. Then in the request handler
definition in solrconfig.xml, I would list that type name
"topic_based_generator" as one type that handler uses to generate queries.
Then in the initialization for the handler it would instantiate the correct
QueryGenerator class that "topic_based_generator" mapped to.
I.e., the handler would check info.name (from PluginInfo info) for the matching
QueryGenerator PlugInfos it got from the SolrConfig for the one matching
"topic_based_generator" then call solrCore.createInitInstance for that class to
get the generator itself.
was (Author: brian44):
I guess it may not be as simple as I thought at first glance.
As of right now with only that change, for new custom types, it seems like the
code for initializing them would have to go in the initialization code of the
component that uses them. I.e., it would be along the same lines as the code
used in SolrCore to initialize the different components, e.g., "initQParsers()"
in SolrCore gets all the plugin classes found in the SolrConfig having the
QParser type and instantiates each.
Here's one way it could work:
For my custom request handler that makes use of the custom plugin type, in a
SolrCoreAware inform method, it would get all the plugin classes defined in the
SolrConfig extending the QueryGenerator plugin type, and based on which are
specified in its parameters, it would instantiate an object of each
QueryGenerator class as needed. So the component that uses the custom plugin
type could be responsible for instantiating and using them (the code could live
there), which would still allow adding new types without any code changes to
that component itself.
I.e., say I wanted to add a new query generator type "topic_based_generator",
then I would define "topic_based_generator" with a particular QueryGenerator
class in solrconfig.xml contained in a new jar I added to the library
directory, like we do for custom query parsers. The pluginInfo would get
loaded by the SolrConfig constructor. Then in the request handler definition
in solrconfig.xml, I would list that type name "topic_based_generator" as one
type that handler uses to generate queries. Then in the initialization for the
handler it would instantiate the correct QueryGenerator class that
"topic_based_generator" mapped to.
I.e., the handler would check info.name (from PluginInfo info) for the matching
QueryGenerator PlugInfos it got from the SolrConfig for the one matching
"topic_based_generator" then call solrCore.createInitInstance for that class to
get the generator itself.
> 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]
