Christian, Perhaps that's why my view of DS isn't as sunny as it could be since I use Camel extensively and did not have great experiences with it and DS. While I know that proxies have their downside and that chaining is preferable, proxies ensure that Camel has what it needs when it runs. When I fire up Fuse with 800 bundles the thought of having to manage start up orders as one more configuration chore is a bit depressing.
I'm very much looking forward to when I can do more work with Karaf 4 and profiles. For most of my clients they are in Fuse back in 2.x however. Brad On Fri, Jul 8, 2016 at 5:54 AM, Christian Schneider <[email protected] > wrote: > I would greatly appreciate if you could look into a better way of > combining camel with DS. > > I recently tried to make camel work with DS and found that the DS support > camel provides is quite complex and does not work well. > See http://camel.apache.org/camel-and-scr.html > The problem are the camel components. These are announced as services and > must be available before you start the camel context. > The camel scr AbstractCamelRunner needs a lot of config to run and still > is not correct. The problem is that it simply adds and removes the > components at runtime > but once the camel context starts it is too late to add a component. > You will not notice the problem in karaf as karaf has very specific start > level settings for the components to make sure they come up early but this > sucks. > > I have used a different approach for a demo: > > https://github.com/cschneider/osgi-chat/blob/master/irc/src/main/java/net/lr/demo/chat/irc/IRCConnector.java > I simply add mandatory references to all components I use. So DS makes > sure my component only comes up once everything is in place and also stops > when some component is missing. > This works fine but is a bit inconvenient. Maybe you have a better idea > how to do this. > > Btw. For CXF support I currently work on improvements for Remote Service > Admin with CXF as a provider I think this is currently the best way to use > CXF in DS but we have to make sure it covers > all use cases people have. The CXF blueprint support allows a lot of > settings and we have to make sure the RSA support can also offer all the > needed customizations. > Hibernate support works quite well now with Aries JPA and JPATemplate or > alternatively with Aries tx-control. > > Christian > > > > On 08.07.2016 02:49, David Jencks wrote: > > > 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]> > [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]> > [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]>[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]>[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]> >>> [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]>[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 >>>> >>>> >>> >> >> > > > > -- > Christian Schneiderhttp://www.liquid-reality.de > > Open Source Architecthttp://www.talend.com > >
