dsmiley commented on code in PR #2126:
URL: https://github.com/apache/solr/pull/2126#discussion_r1441792277
##########
solr/core/src/java/org/apache/solr/core/SolrXmlConfig.java:
##########
@@ -165,6 +166,9 @@ public static NodeConfig fromConfig(
if (cloudConfig != null) configBuilder.setCloudConfig(cloudConfig);
configBuilder.setBackupRepositoryPlugins(
getBackupRepositoryPluginInfos(root.get("backup").getAll("repository")));
+
configBuilder.setClusterPluginsSource(getPluginInfo(root.get("clusterPluginsSource")));
Review Comment:
There's a bigger question of naming. I propose to not make a big naming
change today or even very soon; can be deferred to Solr 10. The internal class
names you have chosen are fine in the mean time; they look relatively obvious
relative to the existing class names, and that's a good thing.
But the user visible aspect should ideally be a name we don't think we're
going to change. I think that's only the "clusterPluginsSource". I can see
why you are making a class name configurable but realistically the user has a
boolean choice to make. And ideally they wouldn't even have to explicitly make
it -- simply define any such plugin in solr.xml and voila -- you get the
NodeConfigClusterPluginsSource internally. If we want a user to make an
explicit choice, then perhaps we can piggyback off of an existing system
properly `disable.configEdit` defined in
`org.apache.solr.handler.SolrConfigHandler#CONFIGSET_EDITING_DISABLED_ARG` as a
general flag for wether config edits are possible. That flag is not publicly
documented yet but we could do so. It currently only applies to editing
configSet at runtime.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
