Jacek Laskowski wrote:
Hi,
I wonder why are the methods of o.a.g.kernel.deployment.AbstractDeploymentPlanner:
protected abstract boolean addURL(DeployURL deployURL, Set goals, Set plans) throws DeploymentException;
protected abstract boolean redeployURL(RedeployURL redeployURL, Set goals) throws DeploymentException;
protected abstract boolean removeURL(UndeployURL undeployURL, Set goals, Set plans) throws DeploymentException;
named this way?
Wouldn't it be better off with the names changed to:
protected abstract boolean deployURL(DeployURL deployURL, Set goals, Set plans) throws DeploymentException;
protected abstract boolean redeployURL(RedeployURL redeployURL, Set goals) throws DeploymentException;
protected abstract boolean undeployURL(UndeployURL undeployURL, Set goals, Set plans) throws DeploymentException;
The names would then be more consistent with the names of the first input parameter (actually redeployURL is so). Also, they would be more meaningful (at least to me :-))
The first time I saw addURL I thought it'd add a URL to the list of deployments to deploy, but quickly realized that it did even more, it added the URL to the list of deployments by deploying it.
Jacek
The intention was that deployment is three phase: 1) work out what needs to be deployed/redeployed/undeployed 2) construct one plan that performs all necessary steps 3) execute that plan
This would allow the planner to resolve dependencies between deployment units in the same batch, to create undo plans that would return the system to a stable state if a deployment step failed, and so on.
So it shouldn't be actually deploying anything - it should be adding the tasks needed to deploy the URL to the deployment plan.
However, this was one of the early features in Geronimo and the component model has evolved substantially since then. For example, I believe the current thinking makes redeployment irrelevant - we would now deploy a new version of the component and undeploy the old one.
It is probably worth looking at the bigger picture here and seeing what can be improved.
-- Jeremy
/************************* * Jeremy Boynes * Partner * Core Developers Network *************************/
