geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Bartel <j...@mortbay.com>
Subject Re: [deployment] hot deploy scanning and redeployment
Date Sun, 05 Oct 2003 13:35:30 GMT
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 <janb@mortbay.com>
> 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



Mime
View raw message