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
