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 >
