[
https://issues.apache.org/jira/browse/JCRVLT-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Georg Henzler updated JCRVLT-254:
---------------------------------
Description:
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.
was:
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.
> 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.
> 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
(v6.4.14#64029)
