dsmiley commented on code in PR #2438:
URL: https://github.com/apache/solr/pull/2438#discussion_r1627752555
##########
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:
We should remove "1. Auto create collection in ZK if it's not already here";
this refers to legacy behavior. Or gate this with "bootstrap_conf" system
property being specified or something like that. Heck, I wonder if this chunk
of code actually works.... like if you did a little experiment locally, could
you get the collection to appear merely by having a core descriptor for a
non-existent collection? I wonder if it's even tested (easy to check by trial
and error).
Hopefully there will be no need to designate this CoreDescriptor as special.
There's legacy stuff you are seeing in Solr. We don't need to support it
forever and ever! Certainly not if it's getting in our way and causing us to
contemplate adding otherwise needless complexity.
--
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
