2017-01-16 13:25 GMT+01:00 Guillaume Nodet <gno...@apache.org>: > > > 2017-01-16 11:36 GMT+01:00 Christian Schneider <ch...@die-schneider.net>: > >> 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. >> > > No, the work I've done on CDI is free from those drawbacks. It has the > same semantics as DS, so anything you can do in DS, you can do in CDI. You > can even do more than DS because you can wire services "internally", i.e. > you don't have to expose your services to the OSGi registry to wire them > together. > > >> >> 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. >> > > I think it's ready. The spec that the OSGi alliance is working on, is > crap imho, but I've raised my hand several times already, so I won't try to > bargain about all the limitations and creepy proxy things they want to do. > That said, the spec has 2 parts, the first one is about CDI applications in > OSGi, and that one is good. The second one is a CDI extension for OSGi > service registry interaction, and that's the one that is bad, bad it's > pluggable, so we can easily use the Pax-CDI one and that will cause no > problems. >
Read "but it's pluggable". > > I think this CDI stuff has all the benefits of CDI + DS without the > drawbacks of blueprint, so I'd rather have us focusing on it. > > >> >> >> 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:cschneider...@gmail.com >> <cschneider...@gmail.com>] *On Behalf Of *Christian Schneider >> *Sent:* Wednesday, January 11, 2017 8:52 AM >> *To:* user@karaf.apache.org >> *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 Schneiderhttp://www.liquid-reality.de >> >> Open Source Architecthttp://www.talend.com >> >> > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Red Hat, Open Source Integration > > Email: gno...@redhat.com > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
