[ https://issues.jboss.org/browse/WFLY-1305?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-1305: ---------------------------------------- I assume the "RESULT" section in the attached operation-outcome.xml is what is assigned to var 'result' at FileSystemDeploymentService L423. So the problem is "result" => {"step-1" => { "outcome" => "success" The operation is actually a composite of composites. So that "step-1" is itself a composite. And it is being marked as "success" even though one of *it's* steps failed: "step-2" => { "outcome" => "failed", "failure-description" => {"JBAS014671: Failed services" => {"jboss.module.service.\"deployment.test.war\".main" => "org.jboss.msc.service.StartException in service jboss.module.service.\"deployment.test.war\".main: JBAS018759: Failed to load module: deployment.test.war:main Caused by: org.jboss.modules.ModuleNotFoundException: aaa.bbb:1.0"}} } This happens because CompositeOperationHandler only marks the composite operation as "failed" if rollback occurs. I have a vague memory that that's by design; I'll need to do some research. FileSystemDeploymentService can likely deal with this by 1) knowing it's executing during boot, which it could learn from DeploymentOperation (which would have to have a property added to reveal that.) 2) If so digging further into that RESULT to look for problems and not relying on the result of the composite. Perhaps it should do that always. That will get the .failed marker correctly written. Analysis/testing also needs to be done to ensure that FileSystemDeploymentService will correctly handle the deployment being subsequently fixed; i.e. it needs to recognize that the deployment is still registered with the server and needs to be replaced, not added a second time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira