aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Zipay <mzi...@gmail.com>
Subject Re: Augmented properties with fallback in Blueprint property placeholders
Date Fri, 30 Aug 2019 23:08:59 GMT
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 <mzipay@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
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message