On 12/11/2004 8:38 AM, David Jencks wrote:
<snip>
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.
I assume so. However, even if a new set of modules are created for those shared classes, it will still be possible to "deploy" successfully a module and not be able to "run" it if the configuration associated to j2ee-server-plan is not one of the ancestor of the module being deployed.
I do not know if this is possible; yet, it seems that if we were able to update dynamically the parent configuration corresponding to j2ee-server-deployer-plan and set it to the parent configuration of the module being deployed, then we will not have this problem: if you can "deploy", then you are sure that you can "run" the module.
In such a case, one does not need to have this new set of modules for the classes shared by the various builders and their associated runtime classes.
Thanks, Gianny
