I strongly suggest that you work on this in the context of an OSGI RFP/RFC. You are apt to get much better advice that conducting the design discussion here. I think it’s fairly ridiculous that after all these years blueprint’s relationship to config admin is unspecified. I think that there are no “blueprint people” other than users these days.
I would also suggest studying at least the R6 config admin spec and understanding multi locations as that will make it clear that blueprint shouldn’t have anything explicit to do with bundle locations and that your concerns about sharing configuration across bundles have been dealt with in the appropriate spec already. In addition I suggest studying the DS R6 multiple pid support as a possible model for what you are interested in. I don’t think your apparent idea of using pid name parsing as the way of relating multiple pids is very scalable or comprehensible. On the other hand, you could approach this all from a management agent perspective and have the management agent merge configuration source data with related “names" into a single configuration. This would work with current blueprint cm. I think that merging data in config admin is an untenable approach. It certainly wasn’t the approach adopted for DS, and I would think getting spec support for it would be difficult. david jencks > On Jul 7, 2016, at 10:53 AM, 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
