Possibly the lack of spec activity on blueprint is because there is only one implementation. However if I were using blueprint I’d be pretty worried that something as essential as cm support isn’t in the spec. Thus, I’m trying to encourage blueprint users to help get it there….
From the original idea of merging data from input files with related names into configuration for one blueprint “thing” I think the most appropriate solution would be a management agent (like enhanced fileinstall) that merged the data before turning it into a configuration. This wouldn’t require any change in blueprint. On the other hand I think a blueprint feature like DS has of support for multiple pids would be pretty useful. Since cm support isn’t spec, someone could just implement it. I’d think that getting it in a spec would lend it a little more credibility. I’m curious what it is you don’t like about (the R6 spec) DS annotations. I think it’s extremely slick to be able to configure your component with an annotation and annotate that annotation to get the metatype that describes the configuration. As far as I know with updated bnd you don’t need to specify any duplicate information, which is fairly new :-). Service order startup is not a reliable way to get anything to work in osgi :-) Mandatory references work pretty well, and if you need several of one kind of thing the <refname>.cardinality.minimum property works great with DS. It sounds like as a DS partisan I should investigate camel and figure out a good DS way to come up with a route :-) thanks david jencks > On Jul 7, 2016, at 4:08 PM, Brad Johnson <[email protected]> wrote: > > 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] > <mailto:[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] >> <mailto:[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 >> >> >> > >
