Re: [deployment] hot deploy scanning and redeployment

[Jan Bartel]

gianny,
Where can I find the resource adaptor deployer code that you refer to? I 
can't seem to find it in CVS ...

Other comments are inline ...
Hello,
From: Jan Bartel <[EMAIL PROTECTED]>
Date: Sun, 05 Oct 2003 18:28:19 +1000
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 ();
}
I agree. I even think that this class should be a MBean and I will 
explain why after. More accurately, this class could extend 
DeploymentInfo and be used as a meta-data repository for a J2EE module 
deployment. 
Sounds good to me.

In your terminology all these attributes could be added to 
WebDeployment.
In my implementation of a generic deployment planner for J2EE modules, I 
use the notion of deployment meta-data:

public class DeploymentMetaData
   extends DeploymentInfo
   implements DeploymentMetaDataMBean {
   public URL getDdURL();
   public URLType getUrlType();
   public GeronimoModuleType getType();
   public ObjectName getClassSpace();
   public Object getPojoDD();
   public Document getRawDD();
}
getDdURL(): Gets the URL of this deployment.
getUrlType(): Gets the URL type of this deployment.
getType():  Gets the deployment type.
getClassSpace(): Gets the ClassSpace used by this deployment.
getPojoDD(): Gets the POJO mirroring rawDD.
getRawDD(): Gets a DOM representation of the DD of this deployment.
This MBean is a meta-data repository for a J2EE module deployment. It is 
created automatically by the generic planner and populated by 
sub-sequent tasks of a J2EE deployment plan.
Yes, this is very closely aligned with what I was suggesting.
For instance, the rawDD and pojoDD attributes are set by a DDLoaderTask. 
BTW, the loaders (e.g. AppClientLoader) do not share the same load mehod 
signature. I understand that it was to promote type safety. However, 
this is not very handy to use them generically (DDLoaderTask uses 
reflection). Moreover, as you may have notice getPojoDD() returns an 
opaque object because the root of our POJO is not common. Perhaps that 
to define a mark-up interface could be applied.
I would have thought it would be very natural to have a common root of 
the POJOs for the deployment descriptors, it seems wrong to me that we 
don't.


At the end of the day, one does not need to provide additional 
information to the registered planners/deployers as this information is 
here and can be easily queried via JMX. Moreover, an end-user will 
appreciate (?, at least I will) to be able to see this meta-data related 
to a deployment.

Moreover, I do believe in a single planner whatever the J2EE module to 
be deployed. Indeed, if one have a planner for each task, it becomes 
really hard to enforce a requirement cross-planner: for instance, 
AbstractWebContainer does its job, but it is not compliant with the 
naming convention of JSR-077. 
Well, the object name of the web app is very easily made compliant. It 
is the way it is at the moment because I was following the pattern 
established by the "hack" jetty deployment. I will ensure it complies to 
JSR077.

It is possible to have a single planner, 
by only defining specific task to configure a container.

To give you a big picture, this is how a resource adapter is deployed 
via this mechanism (excerpt):
       // Create the meta-data deployment unit MBean.
       deploymentPlan.addTask(new CreateMBeanInstance(server, dMetaData));
       // Start the meta-data deployment unit MBean.
       deploymentPlan.addTask(new StartMBeanInstance(server, dMetaData));
       // Create a ClassSpace for the deployment unit.
       deploymentPlan.addTask(new CreateDeploymentClassSpaceTask(server, 
deployName));
       if (GeronimoModuleType.RAR == type) {
           // Load the DD into the POJO.
           deploymentPlan.addTask(new DDLoaderTask(server, deployName, 
loaderMethod));
           // Configure the deployment unit ClassSpace by adding the rar 
archives.
           deploymentPlan.addTask(new RarSetClassSpaceTask(server, 
deployName));
       }
       // Create the actual J2EE module.
       deploymentPlan.addTask(new CreateDeploymentTask(server, 
conDeployMD, deployName));
       // Start it.
       deploymentPlan.addTask(new StartMBeanInstance(server, conDeployMD));
How does this relate to the JSR88 deployment steps and the geronimo hot 
deployment mechanism?

One of the pitfalls I see with this style of central deployer, and the 
type of central deployer that Aaron is proposing, is that every time we 
want to add support for a new type of deployable, we'll have to add another
 "else if (type == blah)" to an ever-growing list within this code.

By maintaining individual deployers implementing standard JSR88/JSR77 
style interfaces for deployment lifecycles (but re-using common code, 
perhaps from an inherited base class) we reduce the coupling in the 
code, therefore gaining maximum flexibility and minimize changes 
necessary to support new deployment types.

We should be able to just drop in a new deployer into a running Geronimo 
instance and have immediate support for the new deployment type. We can, 
and in fact do, do this right now (the web container dynamically 
registers itself as a DeploymentPlanner when it is itself deployed), so 
in moving to a monolithic deployer we would lose this functionality.

Jan