Redeployment: the DeploymentController, if it finds a url or directory that it found on the previous scan, just wraps it in a RedeployURL and sends it off to the deployers to handle. The deployers then have to make the decision whether anything has changed, such as the timestamps on critical descriptors etc. This is quite reasonable, as the items to check for changes will differ with each type of deployment so the DeploymentController can't make these kind of decisions.
It does means that each deployer has to have code for maintaining and checking file timestamps on these crucial files. This is a good candidate for code to go in an AbstractDeploymentPlanner or DeployPlannerSupport class.
Undeployment: as the DeploymentController tries all DeploymentPlanners (called "deployers" for simplicity) until it finds one that will handle the undeployment, it is important that a deployer only attempts to undeploy something that it was capable of deploying in the first place,
(or that it actually did deploy itself ??).
I've just applied a partial patch to the ServiceDeploymentPlanner for just this purpose - it was happily undeploying the mbeans associated with any URL it was passed, rather than just urls that refered to services. The patch is only partial because at the moment, the Service deployer doesn't have enough information to determine if it should undeploy a url if the url refers to anything other than an xyz-service.xml file, for example a packed deployment, or a directory. In the case of packed or exploded deployables, as the deployable has been deleted from the hot deploy directory, it isn't possible to look inside it to deduce it's type in the same way as is done on deployment.
A solution to both of these problems would be for the DeploymentController to maintain some context information for all deployed urls. This context should be available to the deployers on deploy/undeploy/redeploy calls. The class would look something like:
public class DeploymentContext
{
public DeploymentContext (URI uri);
public void addFileTimestamp (URI uri, Date timestamp);
public Map getFileTimestamps ();
public void removeFileTimestamp (URI uri);
public void setDeployer (DeploymentPlanner deployer);
public DeploymentPlanner getDeployer ();
}It would be used in the following scenarios:
1. DeploymentController detects a new url to be deployed: The DeploymentController: - DeploymentContext dc = new DeploymentContext (uri); - associate it with the uri in the set of scan results - invoke plan(goal, plans, dc) on all deployers
A Deployer:
- examines the uri to be deployed to determine if it is suitable
for it to deploy
- if it is, gets the timestamps on any crucial files in the
deployable, eg META-INF/xyz-service.xml and calls
dc.addFileTimestamp(file, timestamp)
- does the deployment
- calls dc.setDeployer (this);
2. DeploymentController detects a url for potential re-deploy: The DeploymentController: - dc = DeploymentContext associated with the url - invokes plan (goal, plans, dc) on all deployers
A Deployer:
- if (dc.getDeployer() == this
||
dc.getDeployer() is same type as myself) then
dc.getFileTimestamps() and compare them to now
if any timestamps are different
update them in dc
do the redeployment3. DeploymentController detects a url for undeployment: The DeploymentController: - dc = DeploymentContext associated with the url - invokes plan (goal, plans, dc) on all deployers
A Deployer:
- if (dc.detDeployer() == this
||
dc.getDeployer() is same type as myself) then
handle the undeploymentNote that a possible refinement would be for the DeploymentController to directly call the deployer responsible for a deployment in the case of redeploy and undeploy eg:
dc.getDeployer().plan (goal, plans, dc);
If there is a problem with the deployer (eg it has died, it is stopped etc) then plan(goal, plans, dc) could be invoked on all the deployment planners (or maybe only those of the same type as a further refinement?) to provide a graceful fail-over to backup deployers.
It might even be possible for the DeploymentController to use the timestamp information provided in the DeploymentContext to determine, in a generic way, whether re-deployment is necessary rather than requiring the deployer to compare timestamps.
NB. This DeploymentContext class could also be the place to make available the preparsed DD POJOs - as per the other current thread
about EAR deployers deploying WARs etc.
