"mark.spritzler" wrote : | So, a listener to get callbacks on the lifecycle of the deploying? What does that interface look like, actually I can just look it up. | | But the run() goes how far, in the case of a war file? | The listener interface just receives ProgressEvents: | public interface ProgressListener | { | void progressEvent(ProgressEvent eventInfo); | } | which is a DeployentID(identifies the deployment) and a DeploymentStatus which provides what target, command, status of command being performed is. There is no difference in the distribute behavior for an mcbeans deployment vs an ear/war. I will be introducing a describe/prepare command as discussed with Brian as part of the farming support in this thread: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151467 "mark.spritzler" wrote : | | | DeploymentStatus status = progress.getDeploymentStatus(); | | assertTrue("DeploymentStatus.isCompleted", status.isCompleted()); | | // It should not be running yet | | assertFalse("DeploymentStatus.isRunning", status.isRunning()); | | assertFalse("DeploymentStatus.isFailed", status.isFailed()); | | | | This confused me just a tad, if only the file has been "copied" but hasn't been fully deployed and started, how is it completed==true. Unless the definition of completed is just that the file has been fully "copied" | completed==true indicates the completion of the command being run. Right now there are the following commands: | package org.jboss.deployers.spi.management.deploy; | public interface DeploymentStatus | { | public enum StateType { | UPLOADING, DEPLOYING, RUNNING, COMPLETED, FAILED, CANCELLED | } | public enum CommandType { | DISTRIBUTE, // Copies the raw deployment contents to a profile repository | START, // Runs the deployment through the full MC deployment states all the way to INSTALLED | STOP, // Uninstalls the deployment from the MC but leaves the deployment in the profile repository | UNDEPLOY, // Removes the deployment from the profile repository | REDEPLOY // Uninstalls the deployment, updates the profile repository and installs the deployment. | } | and a DESCRIBE/PREPARE command will be added. It will validate that the deployment can be successfully configured to the MC DESCRIBED state which is where all dependencies have been resolved. "mark.spritzler" wrote : | | | // Now start the deployment | | progress = mgtView.start("testMCBeansDeployment.beans", DeploymentPhase.APPLICATION); | | progress.addProgressListener(this); | | progress.run(); | | status = progress.getDeploymentStatus(); | | assertTrue("DeploymentStatus.isCompleted", status.isCompleted()); | | assertTrue("DeploymentStatus.isRunning", status.isRunning()); | | assertFalse("DeploymentStatus.isFailed", status.isFailed()); | | | | OK, so by looking at this code, it just looks like all the steps of "deploying" a war are all covered so that any management console can keep track of the entire process, instead of a "one swooping step to follow" from a management perspective. | | Overall, We are pretty flexible in "mapping" the process to fit into the JON plugin notion. So I don't forsee any issue with how you set this up, as usual it is pretty clean and easy to understand. | So the earlier jbossas notions of a single deploy process that included copying/making the deployment available and running are broken up into 3 command steps now: 1. DISTRIBUTE - make the deployment contents available to the profile repository(ies). There may be multiple if clustered. You should comment on the farming thread with regard to what clustering exists at the JON level and how that might conflict/use any native profile service cluster notions. 2. DESCRIBE - validate that the deployment can be run through the deploy process to the MC DESCRIBED state to validate that all references/dependencies can be satisfied. Failure here should return a detailed description of what dependencies are missing. 3. START - complete the deployment processing to bring the deployment components to the MC INSTALLED state. There is no guarantee one can successfully go from DESCRIBED to INSTALLED, so failure to start also needs to provide detailed info on the problems. Charles and I talked about that having invalid deployments as part of the unit test would be needed to make sure the problems are adequately reported to the admin tool layer. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153958#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...