geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: DeploymentPlanner - Base class
Date Wed, 05 Nov 2003 15:38:40 GMT

On Wednesday, November 5, 2003, at 06:32 AM, Jan Bartel wrote:

> gianny DAMOUR wrote:
> [snip]
>>>>> 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

This is what I thought we were doing also.

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

This is much easier with the Geronimo MBean.  I have just finished the 
endpoint code (just testing now), which creates managed connections 
between mbeans.  The component in side the geronimo mbean either gets a 
proxy to the peer or a collection of proxies.  This makes coding mbeans 
that need to talk to each other much 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.

I dislike the idea for forcing a single hierarchy.  If two make more 
sense the, then we should let it happen. The real issue is an mbean can 
pretty much do whatever it wants, so some code could register a 
container without adding it to one of the parents in single hierarchy.


View raw message