You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Matthew Zipay <mz...@gmail.com> on 2019/07/06 23:13:08 UTC
Augmented properties with fallback in Blueprint property placeholders
Hi,
I am interested in submitting a patch to add support for augmented
properties with fallback to Blueprint property placeholders (analogous to
Camel's propertyPlaceholder and its @propertyPrefix, @propertySuffix and
@fallbackToUnaugmentedProperty attributes). I've implemented this as a
customization on a couple projects, but I think there would be value in
having this behavior built in to Blueprint.
Firstly, is there any interest in having this behavior in Blueprint?
If so, I have a couple questions before I open a JIRA ticket and submit the
PR:
1) My changes touch the blueprint-cm, blueprint-core and blueprint-noosgi
submodules. One of the changes I've had to apply is to bump the dependency
version of blueprint-core in the blueprint-cm and blueprint-noosgi POMs
(from 1.10.0 to 1.10.3-SNAPSHOT). Is this acceptable, or is there a
preferred alternative way to handle this?
2) My changes require modifications to the blueprint-cm and blueprint-ext
schemas. Looking at the history of these schemas, I see that their minor
versions have been incremented in the past when new attributes are added to
the property-placeholder element (which is exactly what I need to do). So
I have gone ahead and introduced blueprint-cm-1.5.0.xsd and
blueprint-ext-1.7.0.xsd
(with appropriate corresponding changes in the namespace handlers). Is
this the preferred way to handle this case?
Thanks!
Re: Augmented properties with fallback in Blueprint property placeholders
Posted by Matthew Zipay <mz...@gmail.com>.
Hi, just wondering if there's any feedback on this matter? I'd love to
contribute this change if there is interest.
Thanks
Matt Zipay
On Tue, Jul 16, 2019 at 10:38 AM Matthew Zipay <mz...@gmail.com> wrote:
> Yes, absolutely.
>
> The rationale is that managing multiple configuration files where some
> portion of the properties remain the same while others vary (most commonly
> by environment) results in quite a bit of configuration duplication,
> causing maintenance to be more error prone (and more costly, in general).
>
> Here's an actual use case:
> I have an OSGi bundle that provides functionality somewhat similar to
> PAX-JDBC. This bundle is responsible not only for initializing multiple
> JDBC data sources, but also queue and topic connection factories for Oracle
> AQ, and exporting these as OSGi services. There are multiple databases,
> and multiple AQ instances. But there are also multiple (5+) production
> environments, and certain environments are restricted to using only certain
> databases and AQ instances (a legacy restriction beyond my control). Now,
> for the most part, the configuration properties are generally consistent
> (e.g. JDBC username, pool size). But there are other properties (e.g. JDBC
> URL, password) that must be different for *every* environment.
> So if I were to use PAX-JDBC to define a .cfg file for each permutation
> (target environment) that I need to support, I could easily end up with 20+
> individual .cfg files that need to be managed. What if I need to change
> the pool size? Now I need to make that same edit 20+ times, in 20+
> different files. (We deploy into Karaf and use KARs with embedded .cfg
> files for deployment, so that also means I'd need 20+ different KARs).
> I don't want that - too much to maintain. What I want to be able to do is
> to centralize the configuration into a *single* .cfg file and have a
> *single* KAR that can be deployed anywhere and just "does the right
> thing." To achieve my goal, what I've typically done is create a
> customized property-placeholder with a NamespaceHandler that allows me to
> specify the custom attributes. As a result, I can manage all configuration
> properties in a single .cfg and use an environment-specific prefix so that
> the correct properties are resolved on a per-environment basis (the value
> of the prefix is taken from a system property). I can build one KAR,
> deploy it into an internal Maven repository, versioned, and know that that
> asset can be dropped into *any* environment to provide the correct
> services for that environment.
>
> A visualization may make it clearer. Assume I have two different
> production environments and a test environment.
> My .cfg looks like:
> URL = jdbc:oracle:thin:@test.example.com:1521/sample
> PROD1.URL = jdbc:oracle:thin:@prod1.example.com:20008/regionOne
> PROD2.URL = jdbc:oracle:thin:@prod2.example.com:30015/regionTwo
>
> user = SA_xyzuser
>
> password = ENC(if/ET1EznNl2dga9CtgNl/Xvv1LpdTZ/vAqR/OBnsqw=)
> PROD1.password = ENC(T2HmdkcvzkJkezA62uMpZ0qD9T9QifejAhWy7yXmrBc=)
> PROD2.password = ENC(ooheioanae3L1XX2AMQQdBSmwKmiSjMdqT90PK+QsE8=)
>
> # numerous pooling configuration properties follow...
>
> And in my system properties for the production 1 environment, for example,
> I have defined:
> com.example.fuse.env = PROD1.
>
> Finally, my blueprint (with customized property-placeholder) looks like
> this:
> <ext:property-placeholder
> placeholder-prefix="$SYS["
> placeholder-suffix="]"
> system-properties="override" />
> <custom-cm:property-placeholder
> id="example-property-placeholder"
> persistent-id="example"
> property-prefix="$SYS[com.example.fuse.env]."
> fallback-to-unaugmented-property="true" />
>
> Now I can manage all properties in one place and build one deployment
> asset (KAR). That single versioned KAR can now be deployed into any target
> environment and the properties will be resolved appropriately.
>
> FWIW, this functionality is actually already present in Apache Camel's
> propertyPlaceholder (see https://camel.apache.org/properties.html,
> specifically the fallbackToUnaugmentedProperty, propertyPrefix and
> propertySuffix attributes), and that's what I modeled it after so that I
> can have the same benefits in non-Camel bundles. (It's a behavior that
> I've been asked a number of times, "Why can I do this in Camel but not in
> Blueprint?")
>
>
> On Sat, Jul 6, 2019 at 11:24 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
>> Hi Matthew,
>>
>> can you provide a quick rationale and use case of this change ?
>>
>> Thanks,
>> Regards
>> JB
>>
>> On 07/07/2019 01:13, Matthew Zipay wrote:
>> > Hi,
>> >
>> > I am interested in submitting a patch to add support for augmented
>> > properties with fallback to Blueprint property placeholders (analogous
>> to
>> > Camel's propertyPlaceholder and its @propertyPrefix, @propertySuffix and
>> > @fallbackToUnaugmentedProperty attributes). I've implemented this as a
>> > customization on a couple projects, but I think there would be value in
>> > having this behavior built in to Blueprint.
>> >
>> > Firstly, is there any interest in having this behavior in Blueprint?
>> >
>> > If so, I have a couple questions before I open a JIRA ticket and submit
>> the
>> > PR:
>> >
>> > 1) My changes touch the blueprint-cm, blueprint-core and
>> blueprint-noosgi
>> > submodules. One of the changes I've had to apply is to bump the
>> dependency
>> > version of blueprint-core in the blueprint-cm and blueprint-noosgi POMs
>> > (from 1.10.0 to 1.10.3-SNAPSHOT). Is this acceptable, or is there a
>> > preferred alternative way to handle this?
>> > 2) My changes require modifications to the blueprint-cm and
>> blueprint-ext
>> > schemas. Looking at the history of these schemas, I see that their
>> minor
>> > versions have been incremented in the past when new attributes are
>> added to
>> > the property-placeholder element (which is exactly what I need to do).
>> So
>> > I have gone ahead and introduced blueprint-cm-1.5.0.xsd and
>> > blueprint-ext-1.7.0.xsd
>> > (with appropriate corresponding changes in the namespace handlers). Is
>> > this the preferred way to handle this case?
>> >
>> > Thanks!
>> >
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
Re: Augmented properties with fallback in Blueprint property placeholders
Posted by Matthew Zipay <mz...@gmail.com>.
Yes, absolutely.
The rationale is that managing multiple configuration files where some
portion of the properties remain the same while others vary (most commonly
by environment) results in quite a bit of configuration duplication,
causing maintenance to be more error prone (and more costly, in general).
Here's an actual use case:
I have an OSGi bundle that provides functionality somewhat similar to
PAX-JDBC. This bundle is responsible not only for initializing multiple
JDBC data sources, but also queue and topic connection factories for Oracle
AQ, and exporting these as OSGi services. There are multiple databases,
and multiple AQ instances. But there are also multiple (5+) production
environments, and certain environments are restricted to using only certain
databases and AQ instances (a legacy restriction beyond my control). Now,
for the most part, the configuration properties are generally consistent
(e.g. JDBC username, pool size). But there are other properties (e.g. JDBC
URL, password) that must be different for *every* environment.
So if I were to use PAX-JDBC to define a .cfg file for each permutation
(target environment) that I need to support, I could easily end up with 20+
individual .cfg files that need to be managed. What if I need to change
the pool size? Now I need to make that same edit 20+ times, in 20+
different files. (We deploy into Karaf and use KARs with embedded .cfg
files for deployment, so that also means I'd need 20+ different KARs).
I don't want that - too much to maintain. What I want to be able to do is
to centralize the configuration into a *single* .cfg file and have a
*single* KAR that can be deployed anywhere and just "does the right
thing." To achieve my goal, what I've typically done is create a
customized property-placeholder with a NamespaceHandler that allows me to
specify the custom attributes. As a result, I can manage all configuration
properties in a single .cfg and use an environment-specific prefix so that
the correct properties are resolved on a per-environment basis (the value
of the prefix is taken from a system property). I can build one KAR,
deploy it into an internal Maven repository, versioned, and know that that
asset can be dropped into *any* environment to provide the correct services
for that environment.
A visualization may make it clearer. Assume I have two different
production environments and a test environment.
My .cfg looks like:
URL = jdbc:oracle:thin:@test.example.com:1521/sample
PROD1.URL = jdbc:oracle:thin:@prod1.example.com:20008/regionOne
PROD2.URL = jdbc:oracle:thin:@prod2.example.com:30015/regionTwo
user = SA_xyzuser
password = ENC(if/ET1EznNl2dga9CtgNl/Xvv1LpdTZ/vAqR/OBnsqw=)
PROD1.password = ENC(T2HmdkcvzkJkezA62uMpZ0qD9T9QifejAhWy7yXmrBc=)
PROD2.password = ENC(ooheioanae3L1XX2AMQQdBSmwKmiSjMdqT90PK+QsE8=)
# numerous pooling configuration properties follow...
And in my system properties for the production 1 environment, for example,
I have defined:
com.example.fuse.env = PROD1.
Finally, my blueprint (with customized property-placeholder) looks like
this:
<ext:property-placeholder
placeholder-prefix="$SYS["
placeholder-suffix="]"
system-properties="override" />
<custom-cm:property-placeholder
id="example-property-placeholder"
persistent-id="example"
property-prefix="$SYS[com.example.fuse.env]."
fallback-to-unaugmented-property="true" />
Now I can manage all properties in one place and build one deployment asset
(KAR). That single versioned KAR can now be deployed into any target
environment and the properties will be resolved appropriately.
FWIW, this functionality is actually already present in Apache Camel's
propertyPlaceholder (see https://camel.apache.org/properties.html,
specifically the fallbackToUnaugmentedProperty, propertyPrefix and
propertySuffix attributes), and that's what I modeled it after so that I
can have the same benefits in non-Camel bundles. (It's a behavior that
I've been asked a number of times, "Why can I do this in Camel but not in
Blueprint?")
On Sat, Jul 6, 2019 at 11:24 PM Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> Hi Matthew,
>
> can you provide a quick rationale and use case of this change ?
>
> Thanks,
> Regards
> JB
>
> On 07/07/2019 01:13, Matthew Zipay wrote:
> > Hi,
> >
> > I am interested in submitting a patch to add support for augmented
> > properties with fallback to Blueprint property placeholders (analogous to
> > Camel's propertyPlaceholder and its @propertyPrefix, @propertySuffix and
> > @fallbackToUnaugmentedProperty attributes). I've implemented this as a
> > customization on a couple projects, but I think there would be value in
> > having this behavior built in to Blueprint.
> >
> > Firstly, is there any interest in having this behavior in Blueprint?
> >
> > If so, I have a couple questions before I open a JIRA ticket and submit
> the
> > PR:
> >
> > 1) My changes touch the blueprint-cm, blueprint-core and blueprint-noosgi
> > submodules. One of the changes I've had to apply is to bump the
> dependency
> > version of blueprint-core in the blueprint-cm and blueprint-noosgi POMs
> > (from 1.10.0 to 1.10.3-SNAPSHOT). Is this acceptable, or is there a
> > preferred alternative way to handle this?
> > 2) My changes require modifications to the blueprint-cm and blueprint-ext
> > schemas. Looking at the history of these schemas, I see that their minor
> > versions have been incremented in the past when new attributes are added
> to
> > the property-placeholder element (which is exactly what I need to do).
> So
> > I have gone ahead and introduced blueprint-cm-1.5.0.xsd and
> > blueprint-ext-1.7.0.xsd
> > (with appropriate corresponding changes in the namespace handlers). Is
> > this the preferred way to handle this case?
> >
> > Thanks!
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Augmented properties with fallback in Blueprint property
placeholders
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Matthew,
can you provide a quick rationale and use case of this change ?
Thanks,
Regards
JB
On 07/07/2019 01:13, Matthew Zipay wrote:
> Hi,
>
> I am interested in submitting a patch to add support for augmented
> properties with fallback to Blueprint property placeholders (analogous to
> Camel's propertyPlaceholder and its @propertyPrefix, @propertySuffix and
> @fallbackToUnaugmentedProperty attributes). I've implemented this as a
> customization on a couple projects, but I think there would be value in
> having this behavior built in to Blueprint.
>
> Firstly, is there any interest in having this behavior in Blueprint?
>
> If so, I have a couple questions before I open a JIRA ticket and submit the
> PR:
>
> 1) My changes touch the blueprint-cm, blueprint-core and blueprint-noosgi
> submodules. One of the changes I've had to apply is to bump the dependency
> version of blueprint-core in the blueprint-cm and blueprint-noosgi POMs
> (from 1.10.0 to 1.10.3-SNAPSHOT). Is this acceptable, or is there a
> preferred alternative way to handle this?
> 2) My changes require modifications to the blueprint-cm and blueprint-ext
> schemas. Looking at the history of these schemas, I see that their minor
> versions have been incremented in the past when new attributes are added to
> the property-placeholder element (which is exactly what I need to do). So
> I have gone ahead and introduced blueprint-cm-1.5.0.xsd and
> blueprint-ext-1.7.0.xsd
> (with appropriate corresponding changes in the namespace handlers). Is
> this the preferred way to handle this case?
>
> Thanks!
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com