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. On Fri, Jul 8, 2016 at 7:38 AM, Christian Schneider <[email protected] > wrote: > If you only need very generic configs then using a System property is also > a good choice. You can not change these at runtime but > Aries blueprint can use System properties quite conveniently. > > Christian > > On 08.07.2016 14:11, Brad Johnson wrote: > >> David B, >> >> The Configurator looks like it is on a good track. I'll have to re-read >> to grok all the implications. Interestingly this made me think of an >> interim work around for some of the issues identified in the paper with the >> way the file based blueprint cfg mechanics work. Currently I associate my >> cfg files with my bundles and use features to install and rename them. >> >> But if those cfg files for a subsystem existed in the same bundle then it >> would be easy to create a plugin to merge parent->child properties into the >> final pid.cfg file. Reinstalling the bundle would then trigger a reload on >> bundles specifying that update strategy. One would still end up with one >> bundle/one PID cfg in the end bound to the blueprint properties. But to >> modify something like a common URI for a file location or endpoint could >> happen in a parent cfg file that is then compiled into the various concrete >> PID.cfgs, put into the bundle, and then installed into the system (with >> overwrite = true). >> >> Not an ideal way of doing this perhaps but maybe a way to work around the >> limitations imposed by blueprint's lack of support of multilocations and >> single PID binding. That could also make creating dev/test/production >> configuration bundles easier since that could be a settable parameter. >> >> > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > >
