gianny DAMOUR wrote: [snip]
I thought we'd agreed that a planner of deployments involving subcomponents, such as the ear planner, will call the DeploymentController for every subcomponent that needs to be deployed (war, rar etc) rather than call explicitly to other planner types as you imply here?? I thought we'd agreed it would be better to give the subcomponent to the DeploymentController in order to:
At the end of the day, I believe that DeploymentController should not be the
entry point to action a start, stop, redeployment or undeployment. Why?
Because one knows, which planner has mounted a deployment and hence one can
bypass DeploymentController.
You are assuming that only one planner was involved in the deployment. What about ear and other meta deployments.
My idea is that a ear containing say a rar and 2 war will be represented by the following deployment-units:
- one ear deployment unit;
- one rar deployment unit; and
- 2 war deployment units.
When I write deployment unit, I mean a deployment meta-data repository. The rar and war units are children of the ear one. When an ear is deployed, a ear planner mount the ear unit. This planner then calls the relevant planners for the rar and war units. These planners create units, which are children of the ear unit. When a start action is triggered, the ear unit requests to the ear planner to perform its job. Then all the children units are started. For instance, it means that a start action is triggered on the rar unit, which requests to its planner to perform its job.
* minimize the coupling of the code * make deployments more flexible * re-use the deployment code
I'm not convinced that the ServiceDeploymentPlanner is-a Container. I think it should be a Component. I think a Service instance can be a Container, but is always definitely at least a Component. We could get quite a bit of mileage out of exploiting the Component-Container paradigm a little more in Geronimo. For one thing, it would make implementing some aspects of JSR 77 easier.
BTW, I tried to refactor ServiceDeploymentPlanner and this is not so simple:
ServiceDeploymentPlanner is a kernel service. if one wants to align it with
the proposed approach, then one must re-package a lot of classes from the
core sub-project to the kernel sub-project. For instance, as the proposed
approach defines a class which extends AbstractManagedContainer, one needs
to re-package the Container, Component, AbstractManagedComponent et cetera
classes.
Why is ServiceDeploymentPlanner a Container now? I dislike the idea of pulling this stuff into kernel unless it is absolutely necessary.
I agree. I assume that ServiceDeploymentPlanner is a container because it contains the mounted services.
We should have one Container instance (the "Geronimo" instance) that is the root of the whole containment hierarchy. This Container has children that are themselves other Containers (eg WebContainers, EJBContainers and some types of Services) and Components (eg Services, DeploymentPlanners ...). This would give some uniformity both of structure and function to the disparate parts of Geronimo, yet retain a fairly loose coupling between those parts.
Jan
