Hello,
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 implementation.
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 undeployed.
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 classes.
The new code is referenced by GERONIMO-106: patch-Deployment.jar and patch-Deployment.txt.
Cheers, Gianny
_________________________________________________________________
MSN Search, le moteur de recherche qui pense comme vous ! http://search.msn.fr
