Is your question about whether the empty file should be needed if the user accepts all defaults for SolrCloud, logging, the shard handler factory, and the other defaults for the top-level values, or are you suggesting an alternate location for all of those values if non-defaults are desired? Or, maybe to switch to a solr.properties file since the structure is now rather flat? (Although the shard handler factory has a structured plugin configuration.)
The one advantage of requiring the file is to catch typos like naming the file sol.xml or Solr.xml (for non-Windows, non-Mac) or solar.xml. Or even solr.properties. Otherwise, I’m content to have the file be optional provided that the defaults are all sensible. BTW, it would be nice to do the same for solrconfig.xml. And core.properties, while you’re at it. -- Jack Krupansky From: Erick Erickson Sent: Friday, August 30, 2013 12:42 PM To: [email protected] Subject: So do we even need solr.xml any more? As an experiment while writing a test, I played around with solr.xml and defined it this way: <solr/> Starts up and runs just fine in core discovery mode since it defaults to core discovery mode in the absence of a <cores> tag. Of course all the defaults are used and you better have core.properties files in the right place and all that, but... So does it make sense to officially support a "no solr.xml" option? Removing solr.xml entirely barfs with "solr.xml does not exist in /Users/Erick/apache/trunk/solr/example/solr/solr.xml cannot start Solr" and an empty solr.xml results in an XML parsing error. I don't have strong feelings either way, but thought I'd throw it out for people to kick around. Worth a JIRA? Erick
