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 Tue, 16 Nov 2004 21:13:55 GMT
I talked with Jeremy and Aaron more about this.  Our current idea, very 
similar to one Dain proposed also, is something like this:


1. Each config-builder will be split into two parts: one that needs no 
particular classes and recognizes whether it knows how to build a 
module, and one that may need runtime classes and actually builds the 
configuration for the module.

2. The deployer system will include the "recognizer" parts of the 
builders.  When it's asked to construct a configuration for something, 
it will use its recognizers to find which builders are needed.  It will 
load the chain of parent configurations (which is an entirely separate 
chain of configurations) for the module it's working on, and then 
construct a child configuration of that last parent config containing 
the needed builders.  That dynamically constructed configuration will 
actually build the configuration.

In this way the "statically deployed" part of the deployer system does 
not need to include any runtime classes at all, yet any deployers can 
be added.

The plan I presented below has several serious deficiencies and should 
not be considered further.

If I understand our other conclusions correctly, we think the best 
solution for an offline deployer that can leave newly deployed 
applications so they will start when the server starts is for the 
offline deployer to simply start enough of  server so it can use the 
local config-store and access the list of started configurations 
through the appropriate gbean interface.

thanks
david jencks

On Nov 13, 2004, at 4:45 PM, David Jencks wrote:

> 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