patsonluk commented on code in PR #2438:
URL: https://github.com/apache/solr/pull/2438#discussion_r1625146172
##########
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:
Yes the choice I took was problematic! 😅
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.
Since I saw the quoted code above "reads the config name from cluster state
and set it against the CoreDescriptor", so I thought maybe a new "explicit"
configset can indicate that we can "skip" those logic for `ZkConfigSetService`.
But it didn't turn out well if I confused other devs 😞 ...
Adding any flags/override method in `ConfigSetService` is likely not great
since other non ZK implementation shouldn't really care. So im proposing to add
a new class `SythethticCoreDescriptor` which extends `CoreDescriptor`, and that
`ZkConfigSetService#createCoreResourceLoader` could do a special case
(`instanceof SythethticCoreDescriptor`, not great...but at least it's all
contained in Zk related class) to bypass the zk logic.
Going to commit and push the change, please do lemme know if there are
better alternatives!
--
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
