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

[David M. Lloyd]

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