[
https://issues.apache.org/jira/browse/JCRVLT-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16419919#comment-16419919
]
Jörg Hoh commented on JCRVLT-254:
---------------------------------
[~henzlerg] Of course there are ways to bypass these currently existing
limitations, but from my point of view they are just that: workarounds. I think
that the problem you are trying to solve is more fundamental, and should be
tackled in a different way.
To go one step back: I understand that you have config, which is
system/environment-dependent, and which should be deployed. And it is not
available as part of the build pipeline, but only in at the specific
system/environment.
Why should it be deployed at all? Instead of deploying the configuration into
the system it would be much better to resolve this config at runtime, maybe by
querying an external system. Or in a less dynamic way it should be possible to
inject this configuration without the need to packge it first and deploying it
via vault.
Maybe we should discuss that on the mailing list first.
> 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)
