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

[Jason T. Greene]

On 12/3/10 11:52 AM, David M. Lloyd wrote:
> 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;

It's slightly more extensive, as it's defined as per-application. So 
this means everything in an EAR following the standard isolation rules. 
The important thing though is that it doesn't escape the TLD, which make 
the rules much easier. So we don't have to consider root level ejb jars 
for example.

> we'd extend this to include modular deps as well.

Right although in this case you have already specified the "additional" 
dependency.

>
> 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.

Scott's suggestion is similar how I had been viewing this problem. We 
always import all "global" EE deployments. That's very easy to 
implement, and would work pretty much the same as what we have done 
historically, and complies with the spec.

Auto-detecting is certainly more complex, but would be user friendly, 
and result in less packaging errors.

Explicit module definitions is certainly the "future", and the least 
error prone, but it is border line on spec compliance, so it might need 
to be an optional capability vs a required one. I'm not entirely sure.

-- 
Jason T. Greene
JBoss, a division of Red Hat