geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "gianny DAMOUR" <>
Subject Re: DeploymentPlanner - Base class
Date Wed, 05 Nov 2003 02:07:21 GMT
Dain Sundstrom wrote:

>We absolutely use naming conventions for services.
>*:role=DeploymentUnit,type=<service type>,url=<the url to the deployment>
Yes. Another excerpt of this previous memo ("JSR77 -> JSR88"):

Whatever the type of deployment, a MBean matching the pattern
"*:role=DeploymentUnit,url=" + ObjectName.quote(url.toString()) + ",*" MUST
be created. This is a requirement of the DeploymentController.

>>I also agree. So let me re-phrase: I will write a task to bulk transfer a 
>>file from a remote host. This task will use under the cover WebDAV. My 
>>point regarding the "server push" vs. "client push" idea is that it is up 
>>to the server to mount a WebDAV fie system and not the client to do so.
>I doubt that a server will have access to mount a client's file system.  
>Clients are normally protected by firewall from a server.  Even in a data 
>center you sometimes have servers on a separate physical or virtual lan 
>from you admin machines.  Having the client mount the server webdav 
>directory and push a deployment is way more likely to work.
OK and thanks for that. I will implement the task as suggested. Actually, I 
thought that inbound communications (from the wild and outside world to the 
data center) were more filtered than the outbound ones.

>>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 
>Agree, except you would call startRecursive.
As you may have noticed, I have introduced two methods, namely 
startDeployment and stopDeployment, triggering the starting of a deployment. 
I tried to re-use the JSR77 start and stop methods, however I did face a 
problem. Basically, start and stop are not re-entrant, which causes a 
problem during the execution of a plan in the context of the doStart or 
doStop method. I think that I can avoid this issue and will re-consider my 
current approach.


MSN Messenger 6 : plus de personnalisation, plus 
de fun pour vous et vos amisÂ…

View raw message