Isn't this the Aries discussion forum which has a Blueprint implementation? Why would this be the incorrect place to ask about such issues?
On Thu, Jul 7, 2016 at 2:34 PM, Brad Johnson <[email protected]> wrote: > 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 >> >> >
