I did use it not too long ago but had to get back to a paying gig. But the technology is certainly what we need, I think.
SCR is fine until you then realize that you have wire things up in your bundle and don't have too many good choices about the matter. Blueprint is a little long tooth and clunky to work with. From what I've heard from Christian and others it sounds as though the proxies have naughty habits. I can say that with time I've drifted away from using OSGi services when I have a reasonable choice between using a service and something like a Camel route. A lot of that has to do with the path of least resistance. I'm putting in a system right now that has a data source bootstrapped via PAX JDBC which is then consumed by a "connector" bundle (essentially a DTO). Initially I'd exported that connector as a service for other bundles to pick up and make service calls. But the services seemed to have flaky problems when I uninstalled/installed. Since I had other issues to solve I just fell back to using Camel routes for data access from other bundles. That doesn't seem to be a unique situation for me with Blueprint. Maybe it isn't Blueprint. But the use of services ends up being complex and that's a shame. If there's a technology like CDI that lets me easily export and reference service that will be spectacular. I was stunned about how easy is to test with the CDI anotations. Of course, for bread and butter I'm still consulting on Fuse and that's not exactly cutting edge.... On Thursday, August 10, 2017 at 4:00:52 AM UTC-5, Christian Schneider wrote: > > It is certainly worth to try. I would be very interested in your > experience with the current state of CDI support. > > Christian > > 2017-08-09 17:20 GMT+02:00 <ra...@enjekt.org <javascript:>>: > >> Matt, >> >> This is an exchange between Christian and Guillaume from couple of >> months back when I was asking about this. I've put Guillaume's comments in >> bold. >> >> DI 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.* >> >> >> >> On Monday, August 7, 2017 at 8:34:57 PM UTC-5, Matt Sicker wrote: >>> >>> I'm not so sure about deprecated, but DS is the only dependency >>> injection standard in OSGi that respects the dynamic nature of services. >>> CDI, blueprint, etc., all have to rely on hacky proxies to emulate support >>> while adding nonstandard extensions at times. >>> >>> On 7 August 2017 at 17:02, <ra...@enjekt.org> wrote: >>> >>>> I posted this to the Karaf forum but it may more appropriately belong >>>> here. It's going to be one or the other. >>>> >>>> Has CDI been deprecated from the OSGi specification. I was hoping to >>>> use it in the future instead of Blueprint or DS or in addition to them. I >>>> re all last year a new OSGi service export and reference annotations were >>>> added. So this surprised me a bit. >>>> >>>> https://issues.apache.org/jira/browse/CAMEL-11029 >>>> >>>> According to that issue, Camel's CDI support for OSGi doesn't work >>>> because CDI on OSGi is deprecated. >>>> >>>> -- >>>> -- >>>> ------------------ >>>> OPS4J - http://www.ops4j.org - op...@googlegroups.com >>>> >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "OPS4J" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to ops4j+un...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> Matt Sicker <boa...@gmail.com> >>> >> -- >> -- >> ------------------ >> OPS4J - http://www.ops4j.org - op...@googlegroups.com <javascript:> >> >> --- >> You received this message because you are subscribed to the Google Groups >> "OPS4J" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to ops4j+un...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > -- > Christian Schneider > http://www.liquid-reality.de > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de> > > Open Source Architect > http://www.talend.com > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com> > -- -- ------------------ OPS4J - http://www.ops4j.org - ops4j@googlegroups.com --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to ops4j+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
