[
https://issues.apache.org/jira/browse/JCRVLT-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16292351#comment-16292351
]
Georg Henzler commented on JCRVLT-254:
--------------------------------------
/cc [~kwin] [~bdelacretaz]
> 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)
