[jboss-as7-dev] Deployment Chain/Service interaction

[Jason T. Greene]

On 12/7/10 3:34 AM, Carlo de Wolf wrote:
> 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.)

Right, so in the case of no link and no jndi name, the "type-based 
injection" case, the spec requires, as you mention, that only the 
"application" be searched (which includes Class-path style refs). 
Otherwise the spec indicates that link or jndi info should be provided 
to prevent the ambiguity. We could easily support searching specified 
module refs that have indexing information, but these would be 
statically specified anyway. Searching the whole server in the 
type-based case would likely just lead to errors (aside from being slower).
-- 
Jason T. Greene
JBoss, a division of Red Hat