On Fri 27 Jan 2012 12:53:20 PM CET, Sergey Beryozkin wrote:
> On 27/01/12 11:28, Marek Potociar wrote:
>>
>>
>> On 01/26/2012 05:15 PM, Sergey Beryozkin wrote:
>>> On 26/01/12 15:57, Santiago Pericas-Geertsen wrote:
>>>>
>>>> On Jan 25, 2012, at 8:47 AM, Bill Burke wrote:
>>>>
>>>>>
>>>>>
>>>>> On 1/25/12 5:13 AM, Marek Potociar wrote:
>>>>>> - Should we drop DI and once new CDI extension API is finalized,
>>>>>> should we focus more on CDI instead?
>>>>>>
>>>>>
>>>>> Yes ditch 330, CDI is a much more of a thought out, rich API and
>>>>> interface.
>>>>
>>>> DI on the EE platform is quite confusing even for advanced users. EE 5
>>>> got the ball rolling with @Resource, @EJB, etc. and EE 6 introduced 330
>>>> and CDI with @Inject. If you use @ManagedBean, you use one set of
>>>> annotations, if you use CDI, another :(
>>>>
>>>> JAX-RS did not help the cause by introducing @Context (and
>>>> ContextResolver). So using CDI and JAX-RS, we get:
>>>>
>>>> @Path(…)
>>>> class MyResource {
>>>> @Inject MyBean bean;
>>>> @Context UriInfo ui;
>>>> … }
>>>>
>>>> :(
>>>
>>> There are so many injection mechanisms around...
>>> @Context is a good& *neutral* annotation to enable the injection of the relevant contexts without the users having to
>>> depend on various EE or Spring or other injection-enabling artifacts.
>>
>> I agree that JSR-330 failed to define a standard injection binding API. I would however argue that javax.inject.Inject
>> is much more neutral than JAX-RS specific @Context.
>
> You said it was available at the SE level, but I only see it in EE API.
What I meant is that you don't need EE to use JSR-330. It runs fine on
SE.
> As I said, having DI (@Inject) supported by JAX-RS 2.0 is fine as long as it is only tied to EE containers
I wonder why would we do that? If we wanted to tie DI support to EE
containers, why would we not look into integrating CDI instead of just
DI?
Marek
>
> Cheers, Sergey
>
>>
>> Marek
>>
>>>
>>>>
>>>>> BTW, AFAIK, DI can't handle parameter injection. @Inject isn't even
>>>>> parameter scoped.
>>>>> So I don't see why we should mix the two until that is at least
>>>>> resolved. Also, I"m not sure, but I don't think CDI supports parameter
>>>>> injection either.
>>>>
>>>> CDI supports parameter injection for things called by its container.
>>>> E.g., using @Inject for constructors and setters [1], as well as
>>>> parameter injection for producers, observers, etc. These are not unlike
>>>> resource methods in JAX-RS. As pointed out by Marek, using @Inject at
>>>> method level introduces some challenges like discerning entity params
>>>> (without qualifiers).
>>>>
>>>> In summary, although I acknowledge the issues, I'm not convinced we
>>>> should drop this altogether. In fact, better integration with CDI and
>>>> (at least some) support for 330 are not completely disconnected IMO.
>>>
>>> If something like that is done then IMHO it has to be scoped by the specification section to do with the optional
>>> integration with ESB& CDI, in other words, the user should be able to run a standalone JAX-RS app or wrapped in a war
>>> and deployed to Tomcat and have the injection working without having to bundle DI 330 or CDI artifacts
>>>
>>> That said, there's enough of the *new* useful stuff in 2.0 already, with some other major interfaces being updated or
>>> refactored.
>>>
>>>
>>> Cheers, Sergey
>>>
>>>>
>>>> -- Santiago
>>>>
>>>> [1] http://docs.jboss.org/weld/reference/latest/en-US/html/injection.html
>>>>
>>>