[
https://issues.apache.org/jira/browse/JCRVLT-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra resolved JCRVLT-254.
-------------------------------------
Resolution: Won't Fix
> Support content filtering with environment variables
> ------------------------------------------------------
>
> Key: JCRVLT-254
> URL: https://issues.apache.org/jira/browse/JCRVLT-254
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Reporter: Georg Henzler
> Priority: Major
>
> 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.
> 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 a very short time (milliseconds), 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 PREPARE
> phase to modify the content in the package (I can read it, but not modify it
> I believe). This is why I would like to see this as a "first level citizen"
> in vault itself.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
