Solr.xml to me reflects an earlier age/approach to building Java based apps. These days, instead of .xml files we tend to use env vars / sys props to set things.
I wonder if a solr.properties file that had all the defaults would be enough to eliminate solr.xml? Or, reduce what Solr.xml configures to just those most complex things we don't want to touch? Looking at https://github.com/apache/solr/blob/main/solr/benchmark/src/resources/solr.xml, this is what it might look like as .properties: # Metrics Configuration solr.metrics.enabled=true # Core Configuration solr.shareSchema=false solr.configSetBaseDir=configsets solr.coreRootDirectory=. solr.allowPaths= solr.allowUrls= # Shard Handler Factory Configuration solr.shardHandlerFactory.name=shardHandlerFactory solr.shardHandlerFactory.class=HttpShardHandlerFactory solr.shardHandlerFactory.urlScheme= solr.shardHandlerFactory.socketTimeout=15000 solr.shardHandlerFactory.connTimeout=15000 # SolrCloud Configuration solr.cloud.host=127.0.0.1 solr.cloud.hostPort=8983 solr.cloud.hostContext=solr # This should be high by default - dc's are expensive solr.cloud.zkClientTimeout=60000 solr.cloud.genericCoreNodeNames=true # We are running tests - the default should be low, not like production solr.cloud.leaderVoteWait=15000 solr.cloud.leaderConflictResolveWait=45000 solr.cloud.distribUpdateConnTimeout=5000 # We are running tests - the default should be low, not like production solr.cloud.distribUpdateSoTimeout=30000 I then thought about .yml, as that is very widespread too, and it looks even better: solr: # Metrics Configuration metrics: enabled: true # Core Configuration shareSchema: false configSetBaseDir: configsets coreRootDirectory: . allowPaths: "" allowUrls: "" # Shard Handler Factory Configuration shardHandlerFactory: name: shardHandlerFactory class: HttpShardHandlerFactory urlScheme: "" socketTimeout: 15000 connTimeout: 15000 # SolrCloud Configuration cloud: host: 127.0.0.1 hostPort: 8983 hostContext: solr # This should be high by default - dc's are expensive zkClientTimeout: 60000 genericCoreNodeNames: true # We are running tests - the default should be low, not like production leaderVoteWait: 15000 leaderConflictResolveWait: 45000 distribUpdateConnTimeout: 5000 # We are running tests - the default should be low, not like production distribUpdateSoTimeout: 30000 This could open the door to making it easier to layer global cluster / per node / per collection / per core configuration options. Slightly off-topic, but one of my first OSS contributions was writing https://commons.apache.org/proper/commons-configuration/apidocs/org/apache/commons/configuration2/CompositeConfiguration.html ;-). Eric On 2026/01/20 23:41:52 David Smiley wrote: > If you didn't know, it's an annoying PITA to add a new key-value > configurable to solr.xml. There's a NodeConfig, a builder, fields on both, > getters, setters, the code that actually reads the config... and a > constructor or two from hell. It's not impossible but it's a burden; it's > annoying. It's no wonder that most new settings forgo solr.xml, and I've > been advocating that in the name of less code to maintain, especially for > anything advanced/expert. > > Solr has some pretty excellent env var & system property unification (via > EnvUtils) that conceptually live at the same global/JVM/container level. > But that mechanism is separate without any real relationship with > solr.xml. *Sometimes* these work with solr.xml when we see our solr.xml > containing say > <str name="allowUrls">${solr.tests.security.allow.urls:}</str> > But you usually have to go out of your way to ensure your solr.xml has such > a default to leverage system properties this way. > > So for any given setting, a user might have to use an env var / system > property without the option of using solr.xml. Or you can use solr.xml, > but if you would rather use a system property / env var then you need to > remember to edit your solr.xml to allow for that. The ones supported by > solr.xml are quite arbitrary. > > PROPOSAL: > solr.xml could be improved to add support for mapping any key with a "." in > it to a system property. This allows people to configure settings using > this file if they prefer it. Any setting that solr.xml currently supports > in a way that could be converted, shall be converted (e.g. all of > CloudConfig). Meanwhile, a future version of Solr could remove support for > parsing the elements that can be configured with a system property. It's > simple to document and for users to understand. And it's easy to > maintain. There would remain a need to parse where there's something > structurally interesting, like a custom plugin that wants a NamedList for > initialization. > > Something like shardHandlerFactory is pluggable but has a typical > implementation. The defaults could be handled as described above but still > support the same syntax of today. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
