geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: DeploymentPlanner - Base class
Date Tue, 04 Nov 2003 15:34:12 GMT
	I thought we were going to use the JMX ObjectNames to identify 
deployments, rather than keeping an actual repository somewhere?  I guess 
one of the questions to answer on that score is whether we could put the 
status as a property in the ObjectName and change it as the module is 
started, stopped, etc.  If so, then it's almost a no-brainer to do it that 
way.  If not, then it would be more work to pull out the right subset of 
deployed modules.

	I disagree with your assertion that the server should pull code on
a distribute -- among other things, that assumes that the server can
freely contact that client, which I don't think is necessarily true, or a
good idea.  However I do agree that the distribute call shouldn't block --
I asked earlier if there was a way to stream data to the server over JMX
and got no answer, so I think we need to set up a standard servlet to
receive the data or something.


On Tue, 4 Nov 2003, gianny DAMOUR wrote:
> 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 !  

View raw message