I think this could fall within the assembler or deployer role, depending
on whether the assembler needs to specify an ejb-link or if a binding is
required by the deployer to resolve the ambiguity for lookup.
I don't think an ambiguous reference can be reliably detected on the
client side at deployment time, especially for remote references. This is
more of a runtime check, with the container failing to perform the
injection if there is ambiguity.
-Jeremy
From: Linda DeMichiel <linda.demichiel_at_oracle.com>
To: jsr345-experts_at_ejb-spec.java.net,
Date: 10/30/2012 01:18 PM
Subject: [jsr345-experts] Re: How to handle ambiguity on @EJB
injection?
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