geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Bartel <>
Subject Re: DeploymentPlanner - Base class
Date Wed, 05 Nov 2003 14:32:53 GMT
gianny DAMOUR wrote:
>>>> 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.
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:

  * minimize the coupling of the code
  * make deployments more flexible
  * re-use the deployment code

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

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.


View raw message