Hi George > On Jul 30, 2018, at 4:29 PM, Georg Henzler <[email protected]> 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)
Cool. I probably ran into that a little bit before that. > >>> ... 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 All but the local properties file I wanted to support. I cannot tell about the security implication of allowing a local properties file to avoid hackers to inject code. > > 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 The StringInterpolationProvider should not reside inside the Resource Resolver but in its own or a commons package. For my POC I just kept it there for convenience. > > 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 I started with the etc-mapping as this was the initial use case to move the ball forward. > > 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) The String Interpolation should be not be in the Resource Resolver and hence can be easily used from other modules. Creating a separate module / git repo for just one class this seems to be a little bit of an overkill. Is there any place where we can place that? > > 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. The ticket below is closed with ‘won’t fix’. So I am not sure if Jackrabbit wants to do that. > > -Georg > > [1] https://issues.apache.org/jira/browse/JCRVLT-254 > > >
