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

[Jason T. Greene]

On 12/3/10 12:21 PM, Jason T. Greene wrote:
> 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.

Just to clarify, what I am saying here is that type-based resolution can 
be ignored when it comes to generating deps, because they are already 
known for an "application".

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