Dain Sundstrom wrote: [...] >We absolutely use naming conventions for services. > >*:role=DeploymentUnit,type=,url= 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 >>job. > >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. Thanks, Gianny _________________________________________________________________ MSN Messenger 6 http://g.msn.fr/FR1001/866 : plus de personnalisation, plus de fun pour vous et vos amis…