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

[Scott Stark]

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.