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 callsAnd 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 DeploymentPlanners.
> 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.
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. IfMy 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.
> 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).
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.
Gianny
_________________________________________________________________
MSN Messenger 6 http://g.msn.fr/FR1001/866 : plus de personnalisation, plus de fun pour vous et vos amis�
