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
