Re: Augmented properties with fallback in Blueprint property placeholders

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