[deployment] hot deploy scanning and redeployment

[Jan Bartel <ja...@mortbay.com>]

There is currently a bit of a gap in the handling of hot re-deployment 
and undeployment.

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 redeployment

3. 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 undeployment

Note 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.