As I said on the Camel mailing list Red Hat isn't pushing that approach and I can't push my clients into things they don't want. You and Scott England Sullivan seem to be the ones who think that DS is going to save the world. I have a number of friends in consultancy both inside and outside Red Hat and they don't like or push DS.
On Thu, Jul 7, 2016 at 2:30 PM, David Jencks <[email protected]> wrote: > 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 > >
