geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "gianny DAMOUR" <>
Subject DeploymentPlanner - Base class
Date Tue, 04 Nov 2003 15:21:26 GMT

This is my third try to implement a base deployment planner.

This shot is still very closed to my previous one, however it adds various 
capabilities showing the advantage of such an approach. For the history, 
this approach has been designed by others and I took over the 

The new features are:

* DeploymentContext defines now the following JMX operations:

    public void startDeployment() throws DeploymentException;
    public void stopDeployment() throws DeploymentException;
    public void undeployDeployment() throws DeploymentException;
    public void redeployDeployment() throws DeploymentException;

These operations trigger the expected deployment action on a deployment 
unit. More accurately, it triggers the planning of a deployment context goal 
(package org.apache.geronimo.deployment.goal) and the execution of the 
resulting plan set. The planning is performed by the deployment planner, 
which has mounted this deployment context, and the execution is delegated to 
the DeploymentController.

* A deployment repository has been added in order to track the deployments 
currently mounted. By now, only the "registered" files of deployments are 
tracked. In the future (I need to clean this part), deployment states will 
also be tracked. The goal of this repository is to simplify the 
implementation of ApplicationDeployer.

As I said, "registered" files are tracked. More accurately, a scanner checks 
these files and upon modification executes a command. By now, two files are 
automatically created in order to trigger either the redeployment or the 
undeployment of a deployment. For instance, when an archive module – 
archive.jar in the example - is deployed, the following files are created, 
if required:
archive.jar_REDEPLOY: if one "touch"es this file, then the deployment is 
redeployed; and
archive.jar_UNDEPLOY: if one "touch"es this file, then the deployment is 

These two files are here only as a development convenience.

At the end of the day, I believe that DeploymentController should not be the 
entry point to action a start, stop, redeployment or undeployment. Why? 
Because one knows, which planner has mounted a deployment and hence one can 
bypass DeploymentController.

Hopefully, this approach will simplify the implementation of 
ApplicationDeployer. Indeed, ApplicationDeployer will only leverage the 
above deployment repository in order to perform deployment actions.

Regarding ApplicationDeployer, I am not convinced that we are tackling the 
problem correctly for the distribute operation. It seems that we will always 
distribute and that this is a client push operation. Why always distribute? 
Why a client push? WebLogic has various deployment policies (stage, no 
stage, manual stage), which are more "clever". Moreover, I think that the 
distribute operation, more accurately its "file  transfert" part, should be 
a task. The main advantage is that the call to distribute will not be 
blocking during the "file transfert" execution. In other words, I propose to 
reverse the distribute operation and to opt for a server pull. I will 
implement such a solution in order to show this other approach.

BTW, I tried to refactor ServiceDeploymentPlanner and this is not so simple: 
ServiceDeploymentPlanner is a kernel service. if one wants to align it with 
the proposed approach, then one must re-package a lot of classes from the 
core sub-project to the kernel sub-project. For instance, as the proposed 
approach defines a class which extends AbstractManagedContainer, one needs 
to re-package the Container, Component, AbstractManagedComponent et cetera 

The new code is referenced by GERONIMO-106: patch-Deployment.jar and 


MSN Search, le moteur de recherche qui pense comme vous !

View raw message