geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <djen...@gluecode.com>
Subject Re: Question about deployer classloaders/plan hierarchy.
Date Sun, 14 Nov 2004 00:45:33 GMT
I talked with Dain a bit about this.  We now agree that attempting to 
have the deployment system not be a child of the runtime classes 
creates too many difficulties in writing deployer/builders.  I at least 
am happy to consider other opinions, but I'm satisfied that this is a 
reasonable requirement.

I suggest that we have the following tree of 
configurations/classloaders:

system (as at present)
      |
j2ee-server-classes (a configuration containing only dependencies and 
no gbean definitions: the dependencies are those needed for the j2ee 
runtime gbeans)
      |                                                                  
                                                     |
j2ee-server-gbeans(just gbean defs)                               
j2ee-deployer (dependencies on all builder jars and deployer gbeans)

This way we only need only copy of the j2ee-server-classes, but the 
j2ee-deployer can be loaded only when required.  Furthermore, for the 
"offline" deployer, the j2ee-server-gbeans don't need to be loaded, 
althought their classes are available to the deployment system.

Comments?

thanks
david jencks

On Nov 11, 2004, at 1:38 PM, David Jencks wrote:

> I'd like to get the intended structure for the deployer/runtime 
> classloader/plan hierarchies out in the open and well documented and 
> agreed on.
>
> My understanding is that the desired architecture is to have two 
> independent classloader hierarchies, one for deployment and one for 
> runtime.  The deployer set should not need to include any runtime 
> classes: when you construct a configuration for some module, its 
> classloader will be a child of some other runtime configuration, and 
> any classes needed for deployment will be loaded from that other 
> configuration's classloader.
>
> This desired structure is most emphatically not present today:  the 
> j2ee-deployer-plan includes all the runtime classes and the 
> j2ee-server-plan includes all the deployer classes, plus as an added 
> "bonus", instances of the deployer gbeans.
>
> I believe that we have split out deployment specific code completely 
> enough so that we can divide the server-side hierarchy into two plans:
>
> j2ee-server-plan would contain only runtime classes and gbeans
> j2ee-server-deployer-plan, a child of j2ee-server-plan, would contain 
> the xxx-builder classes and deployer gbeans.
>
> The j2ee-server-plan level would be free from, in particular, xmlbeans 
> code: AFAIK the only xml manipulation is in jetty, and that might be 
> made obsolete by GERONIMO-473. (hmmm. don't know about axis)
>
> However, I think the original goal was to have the builder modules not 
> actually directly use classes from the runtime modules, but allow such 
> classes to be loaded from the configuration's classloader only.  At 
> the moment we cannot achieve this goal because there are several 
> classes that are used both in deployment and runtime.  In particular, 
> there is a POJO model in security and a few classes in connector.  I 
> believe that if we decided to approach the goal of completely 
> independent classloader hierarchies we would need another set of 
> modules for shared classes, or we would have to eliminate these shared 
> classes.
>
> Please comment.
>
> thanks
> david jencks
>


Mime
View raw message