dsmiley commented on code in PR #2438:
URL: https://github.com/apache/solr/pull/2438#discussion_r1625218938
##########
solr/core/src/java/org/apache/solr/core/ConfigSetService.java:
##########
@@ -391,6 +402,21 @@ protected NamedList<Object>
loadConfigSetFlags(SolrResourceLoader loader) throws
*/
protected abstract SolrResourceLoader
createCoreResourceLoader(CoreDescriptor cd);
+ /**
+ * Create a SolrResourceLoader for a core with the provided configSetName.
+ *
+ * <p>By default, this will just call {@link
+ * ConfigSetService#createConfigSetService(CoreContainer)}. Child
implementation might override
+ * this to make use of the configSetName directly
+ *
+ * @param cd the core's CoreDescriptor
+ * @param configSetName an optional config set name
+ * @return a SolrResourceLoader
+ */
+ protected SolrResourceLoader createCoreResourceLoader(CoreDescriptor cd,
String configSetName) {
Review Comment:
> The ultimate goal is to minimize code change and yet avoid calling [this
part of the
code](https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/cloud/ZkConfigSetService.java#L77-L100)
for the synthetic core, so we wouldn't be registering against ZK.
Why? It appears it'd have no ultimate effect -- it ought to resolve the
same config for the same collection. Oh, is it the same collection for this
feature?
I don't love subclassing CoreDescriptor to be honest; you could just add a
generic property in the core descriptor if you needed to flag one like
"synthetic". Nonetheless overall I'm unsure why loading the ConfigSet needs to
be different here.
Also if for some reason we felt it useful, we could change
ZkConfigSetServer.loadConfigSet such that an existing configSet name in the CD
will be used, and thus avoid resolving that.
--
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
