On 12/03/2010 06:45 PM, Jason T. Greene wrote:
On 12/2/10 9:28 PM, David M. Lloyd wrote:
e to add one manifest entry.
> If implicitly detecting EJB interdependencies based on annotations
> becomes a requirement, I see other downsides as well. For example this
> would mean that at a container level, there can only be one EJB with a
> given interface name (otherwise there'd be no way to "wire" reliably),
> which means that deploying multiple EJB JARs defining an EJB with the
> same class or interface name is impossible for no good reason. EJBs are
> normally identified by app name/module name/bean name - or in the case
> of top level EJB JARs, just module name/bean name - and by having
> detection based upon a global EJB name scope we defeat this.
@EJB though specifies a unique bean via either a comp/module ref (which
uses unique identifiers in the DD), OR via lookup and a JNDI path that
points to one of the unique jndi paths of the ejb.
Not entirely true. An @EJB can be ambiguous until the entire deployment
is know at which point we can determine whether we actually have got
ambiguity.
For example @EJB BeanView a; can specify an EJB living in any module of
an EAR. (Or even on the server if we allow resolving JBoss style.)
So at the moment you see the deployment unit of an EJB you know nothing yet.
Carlo