David B, Thanks. Part of the reason I brought this to this thread was another gentleman on the Camel mailing list was trying to figure out how to share configurations across his bundles and wondered if the PID mechanics of blueprint were usable or if there were a way to do it via blueprint. David J pointed out that the multilocation mechanism was the way. But I hadn't heard of that being implemented or available via blueprint. That's when the "blueprint is dead" discussion started.
Brad On Fri, Jul 8, 2016 at 3:50 AM, David Bosschaert <david.bosscha...@gmail.com > 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 <brad.john...@mediadriver.com> > 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 >> > >
