You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Georg Henzler (JIRA)" <ji...@apache.org> on 2017/12/15 12:14:00 UTC

[jira] [Updated] (JCRVLT-254) Support content filtering with environment variables

     [ https://issues.apache.org/jira/browse/JCRVLT-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Georg Henzler updated JCRVLT-254:
---------------------------------
    Issue Type: Improvement  (was: Bug)

> 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
>
> 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)