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 <[email protected]> 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é <[email protected]> > 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é >> [email protected] >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> >
