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

[David M. Lloyd]

On 12/03/2010 01:15 PM, Jason T. Greene wrote:
> On 12/3/10 1:00 PM, David M. Lloyd wrote:
>> On 12/03/2010 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.
>>
>> That's exactly what Scott proposes though: that top-level deployments
>> have a special search scope.
>>
>>>> 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.
>>
>> That just means that by default, it's impossible to deploy two beans
>> with the same class as TLDs, so what's the point of having per-module
>> scope if we just disregard it?
>>
>
> Actually we do have a bit more wiggle room than I am letting on.
> Technically the spec doesn't require that local interfaces be accessible
> at all outside of an application (in fact it was originally intended
> that it they would not be, although I think such a restriction is
> silly). So explicit deps sound reasonable and technically comply
> (although I find the auto-writing notion extremely powerful)
>
> So really the only thing the spec requires is rars that are used, and
> those are much easier to resolve. However, in most cases they are
> accessed through standard interfaces (JDBC/JMS). So we can get by not
> doing it here as well.
>
> I'm fine saying this is a > 7.0 feature, if we choose to do it; however,
> I think we should try and do our processing in a such a way that we
> don't outright prevent it.

Works for me.

-- 
- DML