9:28 p.m.
Comments inline.
On 12/02/2010 08:57 PM, Scott Stark wrote:
I think the introduction of a proper service per deployment phase is
a
good idea.
Can the DUP phase notion be more typed than currently in the jboss-as
trunk so that the DUP phase is self describing?
Yeah definitely. The service value should definitely be relevant to the
implemented phase. We'll have to see how that actually plays out when
it comes to implementation but it would be nice if the value of the
"modularize" phase would be the actual Module or set of Modules produced
by that phase, for example.
I had the same question as Brian regarding module annotations
resulting
in additional dependencies. I'm not following the answer, so to clarify
how a deployment would happen, consider:
ejb1.jar: exports Bean1 interface, imports Bean2 interface
@Stateless public class Bean1Impl implements Bean1 {
+ @EJB Bean2 bean2;
ejb2.jar : exports Bean2 interface, imports Bean2 interface
@Stateless public class Bean2Impl implements Bean2 {
+ @EJB Bean1 bean1;
First of all, how are implicit module dependencies like these identified?
j.d.ejb1.jar.modularize -> depends on exporter of Bean2
j.d.ejb2.jar.modularize -> depends on exporter of Bean1
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.
Does the ejb1.jar module metadata have to express the import of
Bean2,
and likewise ejb2.jar the import of Bean1?
Yes, in one of two ways. They can use Class-Path: to express a
JAR-level dependency, in which case the JARs may only communicate with
one another via pass-by-value, or they can express a modular dependency
(mechanism currently undefined, probably a similar Manifest entry
though) in which case they may use pass-by-reference or pass-by-value
and it becomes a real module->module dependency.
Assuming yes, and classpaths between ejb1.jar and ejb2.jar include
each
others exported classes after "modularize", what is the rest of the
deployment path for ejb1.jar and ejb2.jar through the install phase?
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.
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.
--
- DML