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