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. 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/
