sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Georg Henzler <slin...@ghenzler.de>
Subject Re: /etc/map with Placeholders for farms / dev stack
Date Mon, 30 Jul 2018 23:29:34 GMT
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




Mime
View raw message