After getting into these discussions I started thinking that perhaps I'd move all the configuration files into one bundle and install them from features file that way. I could have dev/test/prod cfg files in that same bundle.
Using a combination of filtered resources and some other mechanics then I can perhaps come up with a way so that com.my.batch.transaction.cfg com.my.batch.accountupdates.cfg have a com.my.batch.parent.cfg and during Maven build it is read into and made part of both the transaction and account updates.cfg files. Those are then put into the configuration bundle. When that configuration bundle is installed the PIDs/properties match the bundles looking for them but contain the common information as already been flattened into them. That configuration bundle could also have test/dev/production cfg files and the features file could permit installing test, dev or production the only difference being which set of configuration files they installed before installing the bundles themselves. On Fri, Jul 8, 2016 at 9:12 AM, Brad Johnson <[email protected]> wrote: > Here's a small example. The two batch processes do very different things > yet share some common configuration information pertaining to directories, > ftp and service endpoints. That configuration information obviously also > varies between dev, test, and production. This is one small part of the > project. The connector project is already a crosscutting concern that > keeps its connection information separated from all the other business > processes/services that use it. Some of the properties have queue names > (SEDA or JMS) that are shared between bundles and use runtime substitution > in Camel. But duplicating configuration information between the bundles > and hand massaging it is error prone and makes refactoring a pain. > > <feature name="someproject" version="${project.version}"> > > <configfile finalname="/etc/com.litle.cfg" > override="false">mvn:com.my.connectors/litle/${project.version}/cfg/configuration</configfile> > <configfile finalname="/etc/com.my.batch.transactions.cfg" > override="false">mvn: > com.my/batch.transactions/${project.version}/cfg/configuration > <http://com.my/batch.transactions/$%7Bproject.version%7D/cfg/configuration> > </configfile> > <configfile finalname="/etc/com.my.batch.accountupdates.cfg" > override="false">mvn: > com.my/batch.accountupdates/${project.version}/cfg/configuration > <http://com.my/batch.accountupdates/$%7Bproject.version%7D/cfg/configuration> > </configfile> > <feature>camel-core</feature> > <feature>camel-blueprint</feature> > snip > > And some route like: > > <to > uri="{{batch.local.outbox}}?fileExist=Append&fileName=${header.outFile}" > /> > > On Fri, Jul 8, 2016 at 8:33 AM, Christian Schneider < > [email protected]> wrote: > >> Can you give some examples of typical config properties that need to be >> shared between these bundles. Maybe they lead to an idea for a different >> design. >> >> Christian >> >> On 08.07.2016 15:09, Brad Johnson wrote: >> >>> Christian, >>> >>> Thanks for the feedback. I'm actually looking for a bit more robust >>> solution. Just the one small project I'm working on now has 12 business >>> processes with a number of OSGi services that provide cross-cutting >>> concerns. In this case they are service like credit card authorization, >>> refunds, etc. CXF front ends them with REST/SOAP and I use recipientList >>> to route them. But each of those business processes use OSGi services that >>> might call out to banks, PayPal, analytics services, etc. Keeping these >>> nicely segregated in their own bundles makes them very testable for the >>> routing, data transformation to/from canonical form, etc. But >>> configuration management is a bit of a pain because of the PID pinning. I >>> use update strategy reload on the bundles so that configurations can be >>> changed in different environments. >>> >>> Until now I've kept my configuration files in each bundle and pop them >>> out using the features install mechanism. But I'm rethinking that based on >>> these discussions. I don't know if the Maven properties plugin would do >>> what I'm thinking about but it might be a platform to develop such a >>> plugin. In this case I'd have a separate configuration bundle with my PID >>> cfgs in them and N levels of parent cfg files. The properties would just >>> be rolled up and written out into PID specific cfg files. If I define a >>> port or directory in a parent then all the children would inherit or >>> override that property. That would permit the use of profiles for dev, >>> test and production as well. Modifying any of the cfg files and then >>> putting that through Jenkins would result in a nice configuration bundle >>> that once reinstalled would trigger a reload. In the end the port or >>> directory or endpoint configuration information would be duplicated in each >>> cfg but it wouldn't require hand massaging of each cfg to change. >>> >>> >> -- >> Christian Schneider >> http://www.liquid-reality.de >> >> Open Source Architect >> http://www.talend.com >> >> >
