[ 
https://issues.apache.org/jira/browse/FELIX-5924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16613762#comment-16613762
 ] 

Georg Henzler commented on FELIX-5924:
--------------------------------------

[[email protected]] In general I think it is a great idea to allow for 
this on an OSGi level. 

For the Sling/Jackrabbit use case there was a discussion about this on the 
mailing list [1] - see option 7 that fits exactly to this ticket. Please note 
that Sling/Jackrabbit applications today typically only have maybe around 30% 
of the docker relevant configs in the OSGi configs directly, other 
configurations come from the content repository (see [2] for an example). 

There was also an issue to allow this via FileVault [2] but the idea was 
rejected.

[1] 
http://jackrabbit.510166.n4.nabble.com/Environment-specific-non-role-based-configurations-td4669795.html
 
[2] 
http://apache-sling.73963.n3.nabble.com/etc-map-with-Placeholders-for-farms-dev-stack-tp4084491p4084745.html
[2] https://issues.apache.org/jira/browse/JCRVLT-254

> Allow to provide/override config key values using env variables
> ---------------------------------------------------------------
>
>                 Key: FELIX-5924
>                 URL: https://issues.apache.org/jira/browse/FELIX-5924
>             Project: Felix
>          Issue Type: Bug
>          Components: Configurator
>    Affects Versions: configurator-1.0.4
>            Reporter: Christian Schneider
>            Priority: Major
>             Fix For: configurator-1.0.6
>
>
> The old configurer allowed to override key/values using env variables. This 
> is very suitable when depolying using docker as it is a standard approach 
> there.
> I propose we also support this for configurator. The data provided in env 
> should override eventual default configs provided inside bundles. 
> If possible we should make sure that the config is still only created once so 
> services do not oscilate.
> With some pointers I might  be able to provide a PR for this.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to