geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "gianny DAMOUR" <>
Subject Re: [webapp deployment] Progress (was Re: [Deployment] Application Deployment Status)
Date Sun, 05 Oct 2003 01:46:45 GMT

From: Aaron Mulder <>
Date: Sat, 4 Oct 2003 10:36:51 -0400 (EDT)
>	I'm arguing to split it up, so we do much of the common reusable
>tasks in a central deployer and then dispatch to a specific deployer for
>the truly custom details.
I definitively agree.

>	Thinking back, I seem to have overlooked how the ObjectName will
>be generated.  Personally I would rather have standard application module
>ObjectNames no matter what container is plugged in, so I'd rather see
>"geronimo.deployment:role=WebApplication,instance=(unique ID)" instead of
>"jetty:...".  So I'd prefer to add a 4th method "getUniqueID" to the 3
>listed above.  But if you feel strongly it could just be "getObjectName"
>and you can construct a Jetty name instead.
Regarding the creation of the ObjectName abstracting a J2EE module, one MUST 
be compliant with JSR-077.

It means that the name should be something like:
"geronimo.deployment:j2eeType=WebModule,name=(unique ID),<various 

It means that the generic planner should be able to handle the unique ID 
name, which could be more or less the TargetModuleID generated when an 
application is distributed or dropped in the deploy folder. And a specific 
implementation could provide the "various properties" such as 
"servletEngine=Jetty,et cetera".

>	So now the sequence is something like this:
>  - common deployer identifies app and modules
As a matter of fact, and based on your idea to share as most as possible the 
tasks related to the deployment of J2EE modules, I have refactored the 
Resource Adapter deployer in order to be implementation agnostic. This 
implementation uses a J2EEModuleDeploymentPlanner, which does this. More 
accurately, it uses under the cover, what I have called a 
ModuleTypeDiscoverer, which returns a GeronimoModuleType (an enhanced 
version of the standard ModuleType).

Right after the module identification, J2EEModuleDeploymentPlanner calls a 
ModuleDeploymentPlanDiscoverer, which plans how to deploy a given 
GeronimoModuleType. The idea behind this ModuleDeploymentPlanDiscoverer is 
to be able to configure via XML how the deployment of a ModuleType should be 

>  - (something) validates EAR
I do not know how to understand validation. Yet, if it means parse the 
deployment descriptors and make sure that there are compliant, then the 
implementation I am working on does this.

More accurately, I have enhanced the current task set (CreatedMBeanInstance, 
StartMBeanInstance et cetera) with a deployment specific task, which is 
AbstractDDLoaderTask. This task load a deployment descriptor. More 
accurately, sub-classes implements an abstract method of 
AbstractDDLoaderTask to validate and load into the POJO the deployment 
descriptors of a given module.

>  - common deployer creates app MBean
I agree. I have created a meta-task, named CreateDeploymentTask which does 
this. More accurately, this is a task, which contains other tasks created 
dynamically depending on the module type.

>  - for each RAR in EAR:
>    - common deployer calls ConnectorContainer to validate a RAR, gets
>      ObjectName for valid ones
This is an approach. However what do you think about requesting only 
additional properties. See my previous comment on the generation of object 

>    - common deployer gets connector MBean class from ConnectorContainer
I agree. CreateDeploymentTask does this.

>    - common deployer creates Connector MBean w/class & ObjectName provided
>    - common deployer sets properties on Connector MBean
This is an approach. Another one is to create a deployment unit MBean at the 
very beginning of a deployment which is a meta-data repository. When the 
Connector MBean is deployed, it just has to retrieve these properties by 
using this deployment unit, which is its parent, and sets itself its 

>    - common deployer tells Connector MBean to generate custom code
>    - common deployer gets ClassSpace from Connector MBean
This is an approach. However, I truly believe that ClassLoader strategies 
can be shared by implementations. Indeed, when a .rar is deployed and 
whatever the connector implementation, we know for sure that the CL must 
reference all the .jar, .so and .dll files contained by this .rar.

Moreover, I really like the idea of being able to configure the CL 
hierarchy. For instance, when a web-app is deployed, there are two classes 
repositories: WEB-INF/classes and WEB-INF/jar. During the development stage 
this WEB-INF/classes is very handy as it hides the classes in WEB-INF/jar - 
I do not know if it is a requirement, however it works pretty well with 
WebLogic. This same mechanism could be applied for all the other modules.

In other words, I think that the CL strategy can be shared. I have 
implemented a composite task, AbstractCreateClassSpaceTask, which does this. 
More accurately, sub-classes can use it to define the CL strategy for a 
given module type. For instance, I have implemented a 
RarCreateClassSpaceSpaceTask, which creates the ClassSpace for a resource 

By now, a resource adapter can be deployed via the 
J2EEModuleDeploymentPlanner. I am still working on it: first round of 
refactoring, and impact analysis of "Is it valid to define meta-tasks". More 
accuratey, how to evaluate that such a task can be executed based on the 
fact that nested tasks can be inter-dependant.

I should be able to submit a proposal, say in 2 days. During this time, if 
you have any concern, please voice them. I will be pleased to re-align the 
implementation based on your feedback.


MSN Messenger 6  : dialoguez en son et en image 
avec vos amis.

View raw message