Hi,

Happy New Year to all!

Finally https://issues.apache.org/jira/browse/SOLR-15960 Unified use of system 
properties and environment variables is now merged!
It exports all SOLR_FOO and ZK_FOO env.vars to be available to the Solr Java 
process and maps them to sys.prop without need for explicit maping in 
bin/solr[.cmd].

Please take it for a spin, and if you find simplifications that can be done in 
bin/solr[.cmd] scripts or docs, feel free to grab those.


I'm planning a followup related to sysprop naming convention in 
https://issues.apache.org/jira/browse/SOLR-17111 
Proposing a strict solr.foo.bar naming, aligning with env name SOLR_FOO_BAR 
instead of our current solr.fooBar camelCase props.
The plan is to support both old and new keys in in 9.x (e.g. both 
"disableAdminUI" and "solr.admin.ui.disabled") and only new from 10.0.
Q: Wil this be such a big change that both variants should work throughout the 
10.x series as well?


Next, I'd love to consider semantic property names. Now we have a mix of 
randomly chosen property names. Some examples:
metricsEnabled 
solr.enableStreamBody 
enable.packages 
solr.clustering.enabled 
solr.shardSplit.checkDiskSpace.enabled 
solr.log.requestlog.enabled
I'd love for us to qualify these with module/submodule, so we get some semantic 
naming structure like

solr.<module>.<submodule>.<key>=foo
E.g. enable.packages would then be solr.packages.enabled (instead of simply 
solr.enable.packages)

To do this across the entire set of solr properties is a much bigger change 
than SOLR-17111. So I propose to tackle only the non-standard ones first, and 
select new names case by case.

If you like the proposal of some standardized naming hierarchy across all 
properties, that is probably something that deserves a design document or a 
SIP..

-Jan

Reply via email to