geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: Kernel Deployer Enhancements
Date Mon, 20 Oct 2003 14:44:09 GMT
On Mon, 20 Oct 2003, gianny DAMOUR wrote:
> I though that you intended to implement these JSR-88 commands via 
> ApplicationDeployer?

	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.

> I had a look to the brand new version of ApplicationDeployer and I am
> not, yet perhaps, convinced:

	Don't worry about what's in there now -- it's if anything a 
placeholder while I wait for proper module deployers to be ironed out.
> IMO, ApplicationDeployer should be a rather hollow component, which calls 
> either a MBean or DC. More accurately, the JSR-88 commands are implemented 
> 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 then 
> 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.

> 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 deployed 
> 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).

> - listen to the registration/unregistration of meta-data MBeans, which 
> encapsulates a TargetModuleID;
> - use these notifications to track the available modules; and
> - listen to the JSR-077 status change notifications broadcasted by the 
> children of these meta-data MBeans in order to assess if a deployment is 
> running or simply available.

	I agree that we can track the module status by listening to these
notifications.  That's not what I was discussing though.  I'm trying to
get more status on the processing of a deployment-in-progress (in order to
provide feedback to the user), I'm not worried about tracking the status
of previously-completed deployment actions.


View raw message