11:31 a.m.
See inline.
On 12/2/10 7:28 PM, David M. Lloyd wrote:
As far as I can see, there is no way to identify the implicit
dependency, because you can't identify the dependency without inspecting
the class, you can't inspect the class without it being loaded and you
can't load the class without its dependencies being present already.
Yeah we could pre-load and analyze the class using Javassist or
something but that adds a lot of startup overhead just so the user
doesn't have 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.
In any case I didn't see this requirement in the EJB spec though I might
have just missed it; that thing is a frickin' tome.
The problem is becoming that ejbs can show up nearly anywhere, and I'm
not sure how well the ejb, servlet, and various javaee specs are
defining the rules for resolving a type based dependency injection. I
don't expect that we will have completely implicit resolution. Mostly I
just want to go through some of the non-trivial cross module issues we
will run into and through redployment into the mix so we understand what
requirements we have to place on deployment modules so that users and
support understand how to deal with the loss of the ear as the basis for
defining resolution boundaries.
I would think we would have to have a logical ear module, when there is
no explicit ear, that groups deployment modules into a resolution
context in order for there to be well defined rules.
In the case of an old-style Class-Path dependency, ejb1.jar and
ejb2.jar
each have a dependency from their "modularize" phase to the other's
"structure" phase to import the other's VFS structure into their module.
This has the effect of copying the class bytes only; each deployment
has their own Class instance for the imported classes.
That call by value semantics
are required across the modules in this
case is something that has to propagate to the service containers in
order for serialization interceptors to be created for local ejbs for
example.
In the case of a new-style module dependency, the same thing occurs
but
the dependency would have to be from the "post-module" to the
"modularize" phase. This is what I discuss a little in the Missing
Stuff #3 heading. In this case, the module is first defined in
"modularize", and in "post-module" the additional module
dependencies
are added and the module is relinked to include the new stuff.
It seems to me that annotation reading and processing, which requires a
full classloading environment, would have to occur in this phase after
the additional dependencies are added, otherwise you'd get CNFE/NCDFE if
an annotation were on a class which used the dependency.
Then, annotation data is combined with descriptor data, and the services
are installed.
So how would the relinking be expressed in terms of the DUP chain
phase
processing? It seems we really have more of a DUP state machine where we
have to transition between "post-module" and "modularize" as we
relink.