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</configfile>
<configfile finalname="/etc/com.my.batch.accountupdates.cfg"
override="false">mvn:
com.my/batch.accountupdates/${project.version}/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 <ch...@die-schneider.net
> 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
>
>
