+1
-dain
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
>>>
>>
|