Re: [jboss-as7-dev] Deployment Chain/Service interaction
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