Hi,

yes this is what I also know about Pax CDI.
For internal wiring it's a std. CDI framework, for external wiring it's
close to what DS does.

>From my point of view, I'd say go for it :)

regards, Achim


2017-08-09 17:20 GMT+02:00 <r...@enjekt.org>:

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



-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

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

Reply via email to