[
https://issues.apache.org/jira/browse/SOLR-15782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17782415#comment-17782415
]
David Smiley commented on SOLR-15782:
-------------------------------------
Perhaps we could establish that the following is the new/preferred way for a
"node plugin" to be defined in solr.xml:
{code:xml}
<pluginTypeName name="optional" class="mandatoryClassName"/> <!-- with optional
initialization as child elements -->
{code}
Where:
* {{pluginTypeName}} can be one of a set of known existing plugin types like
"placementPlugin", "coresLocator", etc.. I'm not sure if we need a general
"plugin" option.
* {{name}} may be provided but is only truly needed for certain plugins. For
example a node level request handler would use this for the path to match the
{{<requestHandler name=/foo}} approach in solrconfig.xml.
+I wrote the above thinking of the user first.+. I understand the
implementation is inconsistent because there are existing plugin types like
coresLocator and others that weren't written that way, and "cluster plugins"
defined somewhere else entirely. But I'd rather shield that from users; that's
just implementation details.
As to which plugin types *could* be defined in a "cluster plugin" way (e.g. via
cluster plugins in ZK and is thus dynamic), maybe they could all be in a
general approach so the user chooses the approach that works for them? I
understand the naming conventions are a little different there -- that's okay.
(leading dot? hyphen separation instead of camel-case)
> Configure custom node/container handlers in solr.xml
> ----------------------------------------------------
>
> Key: SOLR-15782
> URL: https://issues.apache.org/jira/browse/SOLR-15782
> Project: Solr
> Issue Type: Improvement
> Reporter: David Smiley
> Priority: Major
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Since Solr 8.6 via SOLR-14404, it's been possible to define custom
> node/CoreContainer request handlers. However, the current mechanism requires
> the use of cluster properties (in ZooKeeper). That allows for dynamic
> registration (cool) but it's awkward to pre-define them – it doesn't comply
> with an [immutable
> infrastructure|https://www.bmc.com/blogs/immutable-infrastructure/] philosphy
> where node handlers can be defined by configuration local to the Solr node.
> That's solr.xml. So here, I propose that node handlers be defined there,
> perhaps the same as is done in solrconfig.xml.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
