sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruben Reusser>
Subject Re: /etc/map with Placeholders for farms / dev stack
Date Tue, 31 Jul 2018 16:42:00 GMT

I think this is a good discussion - looks like the sling team has to 
make some decisions here and I am glad the etc/map work Andreas did is 
at least sparking a bigger discussion.

 From my point of view using packages and install hooks may work but may 
not be the best solution as it would imply a package install every time 
a change to the configs are necessary.

Not sure if maybe this would need a bigger spec to continue the work and 
alignment on what everybody would like to see


On 7/30/2018 4:29 PM, Georg Henzler wrote:
> Hi Andreas,
>> Install Hooks have their own issues like that they do not work for
>> replication
> Install Hooks work flawlessly with replication since around two years
> (AEM 6.3)
>> and they requires to changes whatever the customer has /
>> provides in order to add the place holders.
> not sure what you mean with this?
>>> ... allowing external URLs is dangerous...
>> I do agree with that and I will remove that from my POC.
> A property file should still be possible... so if we do this
> in Sling, I think the following is needed:
> Property Sources to be supported at minimum:
> * An OSGi configuration
> * A local properties file
> * OS Env variables
> * Java System Properties
> There should be an Felix console plugin to show what is active
> from what source and where the value is used. It should live in
> a bundle named like e.g. and provide
> a simple interface to perform string interpolation on any
> string. This service can then be used by
> * Resource resolver
> * Sling distribution
> * Context-Aware Configuration
> a product like AEM can also use this interface in
> * AEM replication config
> * externaliser config
> To have this mechanism properly rolled out it will take some
> time (until all listed modules properly use the to-defined
> interface)
> IMHO it is not an option to do it locally in resourceresolver
> because
> a) it would result in quite a bit of duplicated code across the
> modules listed above (once we actually start implement it)
> b) if additional sources need to be added in the future (think
> ZooKeeper as one interesting option to receive those env-specific
> values), all consumers would have to be updated (unlikely to
> happen, more likely is to have inconsistent behaviour over time)
> Since the described above is quite a bit of effort, I opt for
> pushing a lower-level approach forward (something like [1] or
> maybe even something on oak level). Then there is only one
> implementation needed and it's available immediately, everywhere.
> -Georg
> [1]

View raw message