I suspect just providing examples and documentation showing the "idiomatic" and preferred way of coding would take care of a lot of those issues. It isn't that one is saying use Jersey or use CXF but that the examples themselves use one and not the other. Blog posts and secondary documentation might show the other libraries and mechanisms but for main-line documentation and examples we could just be mum about the issue. One wouldn't even need to say, explicitly, that this or that is the preferred approach. Just that here is the sample code we provide. An end user can choose to follow it or ignore it and go their own way.
For new and intermediate developers they are simply going to follow the examples they find. For experienced developers they will move to a different idiom if they find it easier to use. As one example, the CDI implementation makes tesing a lot easier than by using Camel Blueprint Test Support. Too often I see groups just throw up their hands and give up on unit or integration testing altogether. Part of that is due to the difficulty of working with CBTS and part of that is due to the fact that the Camel documentation is rather poor at pushing for the use of POJOs over Processors/Exchanges. Something like Processors/Exchanges should be looked at when someone wants to know what's happening "under the hood". While that isn't strictly a Karaf issue, I think it isn't an important overall consideration. Push that single, idiomatic way of working with the stack without saying anything about other mechanisms either pro or con. -----Original Message----- From: Jean-Baptiste Onofré [mailto:[email protected]] Sent: Monday, January 16, 2017 4:43 AM To: [email protected] Subject: Re: karaf boot That's why karaf-boot can provide starter and clearly document pro/cons. End-users will choose the best match for their needs. The same could happen for framework: I would like to create a REST service, should I start with Jersey, with CXF-RS, ... So, if in karaf-boot, it makes sense to support different starters for the programming model (because one service exposed with blueprint can be used from DS for instance), maybe we will have to make some choices as "preferred" solution (for REST service, for JPA engine, etc). Regards JB On 01/16/2017 11:36 AM, Christian Schneider wrote: > I generally like the idea of having one standard way to do dependency > injection in OSGi. Unfortunately until now we do not have a single > framework that most people are happy with. > > I pushed a lot to make blueprint easier by using the CDI and JEE > annotations and create blueprint from it using the aries blueprint > maven plugin. This allows a CDI style development and works very well already. > Recently Dominik extended my approach a lot and covered much of the > CDI functionality. Currently this might be the best approach when your > developers are experienced in JEE. Unfortunately blueprint has some > bad behaviours like the blocking proxies when a mandatory service goes away. > Blueprint is also quite complex internally and there is not > standardized API for extension namespaces. > > CDI would be great but it is is less well supported on OSGi than > blueprint and the current implementations also have the same bad proxy > behaviour. So while I would like to see a really good CDI > implementation on OSGi with dynamic behaviour like DS we are not there yet. > > DS is a little limited with its lack of extensibility but it works by > far best of all frameworks in OSGi. The way it creates and destroy > components when mandatory references come and go makes it so easy to > implement code that works well in the dynamic OSGi environment. It > also nicely supports configs even when using the config factories > where you can have one instance of your component per config instance. > > So for the moment I would rather use DS as a default dependency > injection for karaf boot. It is also the smallest footprint. When CDI > is ready we could switch to CDI. > > Christian > > > On 11.01.2017 22:03, Brad Johnson wrote: >> >> I definitely like the direction of the Karaf Boot with the CDI, >> blueprint, DS, etc. starters. Now if we could integrate that with >> the Karaf profiles and have standardized Karaf Boot containers to >> configure like tinkertoys wed be there. I may work on some of that. >> I believe the synergy between Karaf Boot and the profiles could be >> outstanding. It would make any development easier by using all the >> standard OSGi libraries and mak microservices a snap. >> >> >> >> If we have a workable CDI version of service/reference annotation >> then Im not sure why Id use DS. It may be that the external >> configuration of DS is more fleshed out but CDI has so much by way of >> easy injection that it makes coding and especially testing a lot >> easier. I guess the CDI OSGi services could leverage much of DS. Dunno. >> >> >> >> In any case, I think thats on the right track. >> >> >> >> *From:*Christian Schneider [mailto:[email protected]] *On >> Behalf Of *Christian Schneider >> *Sent:* Wednesday, January 11, 2017 8:52 AM >> *To:* [email protected] >> *Subject:* Re: karaf boot >> >> >> >> Sounds like you have a good case to validate karaf boot on. >> >> Can you explain how you create your deployments now and what you are >> missing in current karaf? Until now we only discussed internally >> about the scope and requirements of karaf boot. It would be very >> valuable to get some input from a real world case. >> >> Christian >> >> On 11.01.2017 13:41, Nick Baker wrote: >> >> We'd be interested in this as well. Beginning to move toward >> Microservices deployments + Remote Services for interop. I'll have >> a look at your branch JB! >> >> >> >> We've added support in our Karaf main for multiple instances from >> the same install on disk. Cache directories segmented, port >> conflicts handled. This of course isn't an issue in >> container-based cloud deployments (Docker). Still, may be of use. >> >> >> >> -Nick Baker >> >> >> >> -- >> Christian Schneider >> http://www.liquid-reality.de >> >> Open Source Architect >> http://www.talend.com > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > -- Jean-Baptiste Onofré [email protected] http://blog.nanthrax.net Talend - http://www.talend.com
