users@ejb-spec.java.net

[ejb-spec users] [jsr345-experts] Re: Re: How to handle ambiguity on @EJB injection?

From: Marina Vatkina <marina.vatkina_at_oracle.com>
Date: Tue, 27 Nov 2012 16:09:39 -0800

Experts,

Do you think it's worth adding a specific exception for this case?

thanks,
-marina

Carlo de Wolf wrote:
> EJB 3.1 FR 11.5.1.1 "The target of the reference must be resolved by
> the Deployer,
> unless there is only one session bean component within the same
> application that exposes a client view
> type which matches the EJB reference."
>
> Ah yes, I see it now. Yes, I would have expected it of the Application
> Assembler. I think we can safely introduce an
> AmbiguousResolutionException now without affecting backwards
> compatibility then. That should be part of "Container Provider's
> Responsibility", not?
>
> Carlo
>
> On 10/30/2012 07:18 PM, Linda DeMichiel wrote:
>> This is covered in section 11.5.1.1 (Injection of EJB references).
>> Are you suggesting that this
>> be updated to specify Application Assembler rather than Deployer?
>>
>> On 10/30/2012 1:52 AM, Carlo de Wolf wrote:
>>> I would like to enter a feature request similar to CDIs handling of
>>> ambiguous dependencies [1].
>>>
>>> With a statement of:
>>>
>>> @EJB BeanInterface bean;
>>>
>>> multiple EJBs might be eligible for injection.
>>>
>>> As long as the environment onto which the application is deployed
>>> does not change, the actual injection will likely stay
>>> the same every time it is performed. However should, for example, a
>>> JDK version be updated or another JDK implementation
>>> be used. The actual injection might change.
>>>
>>> So I would rather see that EJB 3.2 EDR 16.5.2 be updated that an
>>> Application Assembler must ensure each EJB reference
>>> resolves to a single EJB. If not, it would be construed as a
>>> deployment error (in the likes of
>>> AmbiguousResolutionException).
>>>
>>> This should be entered as a feature request as it would break
>>> backwards compatibility. Alternatively we could just
>>> demand a warning be logged.
>>>
>>> Anybody opposed to having an 'AmbiguousResolutionException'?
>>>
>>> Carlo
>>>
>>> [1] CDI 1.0 FR 5.2.1 Unsatisfied and ambiguous dependencies
>