geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "gianny DAMOUR" <>
Subject Re: Kernel Deployer Enhancements
Date Mon, 20 Oct 2003 23:38:47 GMT
Aaron Mulder wrote:
>	My intention was that the initial call goes to the
>ApplicationDeployer, and it assembles a series of goals and hands those
>over to the DeploymentManager to execute.  The DeploymentManager already
>has the plumbing for that sort of stuff, and this way the
>ApplicationDeployer can delegate to a DeploymentPlanner to assemble
>specific execution steps for each module type instead of performing those
>steps itself.
Until here, I understand.

> > IMO, ApplicationDeployer should be a rather hollow component, which 
> > either a MBean or DC. More accurately, the JSR-88 commands are 
> > like this:
> >
> > - start: simple call to a MBean (use the JSR-77 capabilities);
> > - stop: simple call to a MBean (use the JSR-77 capabilities);
> > - undeploy: unregister a MBean;
> > - distribute: what has been implemented without the "ServerTargetModule
> > section" and then call to DC; and
> > - redeploy: composite operation equivalent to undeploy, distribute and 
> > start.
>	Rather than hardcoding these operations into ApplicationDeployer,
>I would prefer to pass a Goal to the DeploymentController and then let a
>DeploymentPlan be created for that goal and then executed by the
>DeploymentController.  I would prefer to use the existing
>DeploymentController infrastructure, and let it handle the ordering and
>error handling and so on so all deployment steps are executed by the same
>hunk of logic.  Additionally, this would better support any custom steps
>needed by different module types.  But I would need to enhance that hunk
>of logic a bit to provide more status/feedback as it works.
And here, I do not understand. The fact that one skips DC does not mean that 
one also skips a DeploymentPlanner. Indeed, AFAIK, DC is only a "bridge" 
between a Deployment Scanner and a set of Deployment Planners. DC is a 
"dumb" component, which does pretty nothing: it only tries the registered 

My point of view is simple: one uses DC only to find an adequate 
DeploymentPlanner. When this is done, one simply skips it. Indeed, if one 
wants to stop a module, then it is pointless to use DC as one already knows 
which DP has been used to mount it.

It is possible to bypass DC because the meta-data MBean (sorry for this 
recurrence) has a reference to its DP. In other words, to 
start/stop/undeploy a module the flow is:

ApplicationDeployer -> meta-data MBean -> DeploymentPlanner -> 
DeploymentController (only used for its execute plan capabilities).

The point is that DC does not remenber which DP has deployed what. So, it 
tries dumbly the available DP.

> > I though that you intended to implement a pure event-driven solution. If
> > yes, then one does not need this change:
> >
> > For instance, one can:
> > - defer the creation of a target module ID until a URL is actually 
> > by a deployment planner;
>	I'm not sure if I disagree with your terminology or your idea;
>nevertheless, we must create the TargetModuleID at the time of
>"distribute" not at the time of "deploy" ( = distribute + start).
My idea is: when one calls distrute, ApplicationDeployer stores somewhere 
the module archive. It then simply calls DC. DC tries the available 
DeploymentPlanners. A suitable DeploymentPlanner performs the required 
post-distribution steps (e.g. generate a plan to mount the service). At this 
stage the module is only mounted (MBeans are registered and ready to be 
started) yet not started.

To start a module, one uses the meta-data MBean as the point of entry.

The TargetModuleID is generated during the post-distribution steps. This is 
a drawback and I need to think about it.


MSN Messenger 6 : plus de personnalisation, plus 
de fun pour vous et vos amisÂ…

View raw message