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
