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

[David M. Lloyd]

On 12/03/2010 11:31 AM, Scott Stark wrote:
> 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.

Yeah agreed.  From what I've seen, the rules are fairly well-defined 
though I didn't look into servlet in detail yet.

> 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.

Yeah maybe, though EAR specifies some extra stuff that we won't have, 
i.e. a big flat classloader.  I don't know if we want all top level 
deployments to always share a resolution context though.  I think that 
not everyone will want this, and it's much easier to define this in "opt 
in" terms than in "opt out" terms.  I.e. it's not too big a deal to just 
have them add a "Dependency:" (or "Class-Path:", if they're feeling 
old-fashioned) manifest entry listing other JARs they want to interact 
with, and each JAR's (type-based) resolution scope is then driven by its 
modular and class-path dependencies (which fits nicely with how it is 
defined by the JavaEE platform spec).

>> 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.

Yeah definitely.  We started working this out in Antwerp but ran out of 
time.  I'm working up an AS7-JavaEE integration requirements doc where 
hopefully this will be spelled out but it's going to need a lot of work 
before I'm comfortable that we've hit all the angles.

>> 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.

If we do need a relinking phase (and maybe we won't, depending on how 
Jason's Jandex work goes), it'd only be a two phase thing, which is to 
say, you only get one chance to relink.  I know of no good way to make 
it cyclic without introducing possible problems like deadlocks and 
dependency errors, and honestly the simpler we can keep this, the better 
off everyone will be.

In the very worst case if two phases aren't enough we could make it 
three or four, basically a fixed number.  But I have a feeling that the 
result would be more painful than useful.
-- 
- DML