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

[David M. Lloyd]

On 12/03/2010 11:45 AM, 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.

Yes, and @Resource works the same way I believe.  However I think it's 
OK to require the dependency to be available by one of the two 
mechanisms to have this actually work.  The alternative is pretty 
complex - i.e. using some rule-based strategy to determine what implicit 
dependencies to add - but maybe it's something we can add in a later 
release?

In other words, there are two issues at play:

1. Type-based resolution.  By spec, this happens in the scope of what is 
available via Class-Path; we'd extend this to include modular deps as well.

2. Actual availability of implementation classes.

My feeling is that both should be handled via explicit dependencies in 
all cases.  Scott is saying that these could be implicit by treating all 
top-level deployments as a part of a sort of implicit "super-EAR" in 
terms of #1 and consequently #2 to auto-wire dependencies at this level, 
which is *possible* but I argue is too complex to be worth it - at least 
in 7.0.0.GA.  We'll have problems enough getting the simple cases to 
work without borrowing trouble for the first release.
-- 
- DML