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. On Fri, Jul 8, 2016 at 3:50 AM, David Bosschaert <[email protected] > wrote: > Hi Brad, > > In OSGi currently the concept of a Configurator is being developed. It's > orthogonal to Blueprint or DS and can be used with either of them. It might > touch on the ideas that you mentioned here. You can find the current > configurator design in RFC 218: > https://github.com/osgi/design/tree/master/rfcs/rfc0218 > Maybe this might be something that could be of use. > > Additionally, the OSGi ConfigAdmin spec permits the same configuration to > be consumed by multiple bundles. That might also be of use to you if you > want to share configurations. The bundle location for the configuration > should be set to '?' in that case (see Config Admin spec 104.4.1). > > Cheers, > > David > > PS feedback on the RFC is appreciated, see here: > https://github.com/osgi/design > > On 7 July 2016 at 18:53, Brad Johnson <[email protected]> > wrote: > >> As I work in more environments now that want to use microservices the >> limitations of the blueprint properties mechanics become a bit hairier. I >> commonly find that I have bundles that have common properties shared across >> them and I can't find a good solution other than creating my own OSGi >> service for serving them up for such crosscutting concerns. >> >> I'm not an expert on the specification and implementations of compendium >> or blueprint libraries so don't know how feasible something like this would >> be but I would find the following terribly useful. >> >> A properties hierarchy much like Maven that permits you to specify a >> parent that you inherit from and then can add to or override. >> >> com.foo.parent.cfg >> com.foo.child.cfg >> >> The child cfg file might have a #! directive at the top specifying >> com.foo.parent PID. And if another one was >> >> com.foo.grandchild.cfg >> >> it might specify com.foo.child as its parent. Then the CM would load >> parent, override it with child and finally override that grahdchild. >> >> Yes, I'd still have to specify >> >> <cm:property-placeholder persistent-id="com.foo.granchild" >> update-strategy="reload"> >> >> in my bundle and that would still be bound to that single bundle but this >> could alleviate the need for replication of properties across a lot of >> bundles. >> >> Technically that is all rather straightforward but I'm not sure how well >> that would align with the specifications or goals of CM. >> >> Brad >> > >
