geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <gr...@mortbay.com>
Subject Re: [deployment] hot deploy scanning and redeployment
Date Sun, 05 Oct 2003 13:19:01 GMT

just a couple of comments.

I think it is a probably true that the DeploymentContext could be the
same object that stores the deployment state.  However I think it would
be best to consider them separately for the purposes of this discussion -
at least until we get some more general agreement on these two related
areas.

I think the DeploymentContext or MetaData needs to be able to provide
multiple DD's.  We may have an ear DD, a war DD and maybe a deployment
state DD.

I'm still a big -1 on a single planner.  A single planner will not
allow G to be extended simply, it will be a point of contention with
developers and a source of synchronization issues.

cheers



gianny DAMOUR wrote:
> 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. 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.
> 
> 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.
> 
> 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. 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));
> 
> I will migrate AbstractWebContainer and submit a preview.
> 
> Gianny
> 
> _________________________________________________________________
> Hotmail : un compte GRATUIT qui vous suit partout et tout le temps ! 
> http://g.msn.fr/FR1000/9493
> 
> 



Mime
View raw message