geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Question about deployer classloaders/plan hierarchy.
Date Wed, 17 Nov 2004 22:52:54 GMT


On Nov 16, 2004, at 1:13 PM, David Jencks wrote:

> 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

View raw message