Georg Henzler created JCRVLT-254:
------------------------------------
Summary: Support content filtering with environment variables
Key: JCRVLT-254
URL: https://issues.apache.org/jira/browse/JCRVLT-254
Project: Jackrabbit FileVault
Issue Type: Bug
Reporter: Georg Henzler
There are two use cases, where it would nice to have an option to "dynamically"
adjust content upon installation time:
1. Replication Agents (or in a pure open source world: any content node
properties that hold URI-references to external systems that might differ on
environments or more generically, any content node properties that shall hold
different values on different environments, e.g. on/off switches)
2. OSGi configurations: URLs to other systems (e.g. Stage->Stage/Prod->Prod
Mappings) Externaliser config etc., everything that we commonly do with run
modes today
Today we solve this by
1. creating a package per environment, custom tools or manual configuration
(worst case)
2. runmodes
When talking about cattle and not pets (having an at implementation time
unknown magnitude of servers), the problem is that today's solution becomes
fairly complex.
The idea would be to allow system environment based rewrites of properties
during package installation time (iff a package property is set to allow for
this). This would be used sparsely/wisely to automatically set certain
configuration options that cannot be known at implementation time (most OSGi
configs would remain fixed according to runmodes that are roles, but for some
this approach could be used).
As a POC I created an install hook that does the same thing:
https://github.com/ghenzler/apply-system-env-install-hook
However the problem with this approach is that I cannot avoid saving a property
twice - although the original values with variable placeholders will only be
saved/active in the repo for ms, it will still trigger events (e.g. activating
an OSGi config twice in a row, first with an incorrect value). I'm not aware of
a way to use the INSTALL phase to modify the content in the package (I can read
it, but not modify it I believe). This is way I would like to see this as a
"first level citizen" in vault itself.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)