You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@solr.apache.org by David Smiley <ds...@apache.org> on 2026/01/20 23:41:52 UTC
solr.xml and simple key-values
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
Re: solr.xml and simple key-values
Posted by Eric Pugh <ep...@apache.org>.
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: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org