Georg,
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
Ruben
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. org.apache.sling.systemenv 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] https://issues.apache.org/jira/browse/JCRVLT-254
