[jboss-jira] [JBoss JIRA] (WFLY-1305) a file-scanner deployment that fails on boot will not be undeployed after failure

[Brian Stansberry (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797234#comment-12797234 ] 

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.
                
> a file-scanner deployment that fails on boot will not be undeployed after failure
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1305
>                 URL: https://issues.jboss.org/browse/WFLY-1305
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Toby Crawley
>            Assignee: Chao Wang
>         Attachments: operation-outcome.xml
>
>
> When an app is deployed via the deployments/ dir, but fails for some reason, it is marked as failed with a .failed marker and undeployed. When the AS is rebooted, it tries to redeploy the failure. If this deploy also fails, this new deployment *isn't* undeployed, and a .deployed marker is written to deployments.
> This is with the 7.2.0.Final used in Immutant, I've yet to try to build Immutant on top of 8.x.

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