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 we’d 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
I’m not sure why I’d 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 that’s 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
