Interesting that there should be such a discrepancy from what I see in the field and the specification work that's going on. If you look at the releases related to Aries, for example, the multiple blueprint projects have had multiple releases and updates this past year. Just looking at the Maven repo shows an incredible amount of activity. The Blueprint CM 1.0.8 was just released this March.
I sound like a blueprint advocate but I'm not really. I actually loathe working in XML. Believe me I've had a few years of blueprint headaches and have more than enough complaints about it. I just need pragmatic ways of wiring Camel and OSGi services together for enterprise applications with the dependency injection and OSGi interoperability and Camel EIPs that blueprint provides. If something better comes along then great, I'm all for it. But I've also had enough experience withe Camel Java route builders to not really want to get into them again (despite the advantages in the IDE). And SCR annotations are pretty ugly quite frankly (I know, everyone has their own opinion of that). While I find the debate about proxy versus cascading services mildly interesting from an intellectual standpoint it isn't of tremendous importance to me. What is important to me is that my EIPs and routes work when I'm counting on a service reference being available. But I guess I can always dip into service order start up to hopefully make such guarantees. Perhaps someday when someone writes that enterprise Camel with SCR book that makes it all easy and great in the day-to-day enterprise development world with CXF, JMS, Hibernate and so I'll flip to declarative services and abandon Blueprint. In the meantime I'm stuck with it as a tool. Frankly if DS is the only game in town for the future then perhaps it'll be time to explore the wider world of technologies. On Thu, Jul 7, 2016 at 4:48 PM, David Jencks <[email protected]> wrote: > 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] > > 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 >>> >>> >> > >
