Well, its the user list rather than dev list, but that’s minor. My point is that you are suggesting designing some new functionality for (possibly) blueprint. I suggest that if you want to end up with a good design, you get osgi experts involved. In my experience this results in a much improved design over what I can come up with by myself.
You are also telling me that blueprint is very popular among osgi users. My personal impression from working on osgi specs is that blueprint is regarded as basically dead as there has been no spec activity since IBM pushed the original spec. Getting involved in updating the blueprint spec for R7 might be a good way to popularize the benefits of blueprint — just because I don’t see them doesn’t mean they aren’t there. Finally, I’m not convinced that you have a good understanding of the different services and their currently specified behavior. If multi-location solves your problem and you are on R4.2 the solution is not to reinvent it for R4.2 or blueprint but to upgrade to R5+. thanks david jencks > On Jul 7, 2016, at 12:38 PM, Brad Johnson <[email protected]> > wrote: > > 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] > <mailto:[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] > <mailto:[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] > > <mailto:[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 > > >
