Hi Robert,
* An OSGi configuration
* A local properties file
* OS Env variables
* Java System Properties
Bringing this out a new thread as I think it will slip by otherwise.
IIUC, you suggest that we extend the Sling configuration mechanism by
making other sources first-class besides OSGi. What are the use cases
for that? Currently we delegate almost everything to OSGi component
configurations, with some settings falling back or reading from
framework properties ( which can also fall back to system properties ).
The use cases are described in [1] (first part). At the moment there are
two common config sources for Sling: OSGi configs and content resources
(/etc/maps, rewriter, context-aware configs, etc.). My suggestion is
exactly to not introduce more sources, but rather have for very few
uses cases given in [1] (Hosts/ports, admin passwords) the ability to
"pre-process" the configs before they become visible+effective to Sling.
Only for that pre-processing I would love to see the four options from
above to start with (best case with an SPI for extensibility, and best
case without changing all code that should be able to consume it).
Now Jörg suggested the context-aware configuration override mechanism
[2]
which makes sense except that all relevant configuration parts
like distribution/replication agents, externaliser and other OSGi
configurations (e.g. for jdbc db configs or search engine end points)
are not configured via caconfig today.
-Georg
[1]
http://jackrabbit.510166.n4.nabble.com/Environment-specific-non-role-based-configurations-td4669795.html
[2]
http://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration-override.html
