Re: Configuration property sources with Sling

[Georg Henzler <sl...@ghenzler.de>]

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

RE: Configuration property sources with Sling

[Stefan Seifert <ss...@pro-vision.de>]

>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.

and caconfig was never intended as a replacement for system configuration, but only as an addition for context-aware configuration which cannot be managed elegantly as OSGi configurations. most sensitive configurations like jdbc configs etc. are system configurations and in most cases not context-aware.

stefan