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
