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.
As I said, having DI (@Inject) supported by JAX-RS 2.0 is fine as long
as it is only tied to EE containers
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
>>>
>>