Uploaded image for project: 'WildFly Core'
  1. WildFly Core
  2. WFCORE-4246

FileSystemDeploymentService#handleNotification() can create an unneeded deployment marker file even if scanEnabled="false" is specified

    Details

    • Steps to Reproduce:
      Hide

      1. Set scanEnabled="false" in the deployment-scanner subsystem:

      /subsystem=deployment-scanner/scanner=default:write-attribute(name=scan-enabled,value=false)
      

      like:

              <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
                  <deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-enabled="false" ...(snip)... />
              </subsystem>
      

      2. Place a file which has the same file to the deployment (e.g. test.war) under the deployments directory:

      $ touch $JBOSS_HOME/standalone/deployments/test.war
      

      3. Start JBoss/WildFly. At this moment, a marker file "test.war.deployed" is not created as expected.
      4. Deploy the real deployment (e.g. test.war) through CLI:

      [standalone@localhost:9990 /] deploy /path/to/test.war
      

      5. A deployed marker file "test.war.deployed" is created unexpectedly.
      6. Undeploy the test.war through CLI:

      [standalone@localhost:9990 /] undeploy test.war
      

      7. An undeployed marker file "test.war.undeployed" is created unexpectedly.

      Show
      1. Set scanEnabled="false" in the deployment-scanner subsystem: /subsystem=deployment-scanner/scanner= default :write-attribute(name=scan-enabled,value= false ) like: <subsystem xmlns= "urn:jboss:domain:deployment-scanner:2.0" > <deployment-scanner path= "deployments" relative-to= "jboss.server.base.dir" scan-enabled= " false " ...(snip)... /> </subsystem> 2. Place a file which has the same file to the deployment (e.g. test.war) under the deployments directory: $ touch $JBOSS_HOME/standalone/deployments/test.war 3. Start JBoss/WildFly. At this moment, a marker file "test.war.deployed" is not created as expected. 4. Deploy the real deployment (e.g. test.war) through CLI: [standalone@localhost:9990 /] deploy /path/to/test.war 5. A deployed marker file "test.war.deployed" is created unexpectedly. 6. Undeploy the test.war through CLI: [standalone@localhost:9990 /] undeploy test.war 7. An undeployed marker file "test.war.undeployed" is created unexpectedly.
    • Workaround Description:
      Hide

      This issue does not happen when the deployment-scanner subsystem is completely disabled. If the deployment scan is not needed, you can avoid this behavior by removing the deployment-scanner subsystem instead of setting scanEnabled="false":

      /subsystem=deployment-scanner:remove()
      
      Show
      This issue does not happen when the deployment-scanner subsystem is completely disabled. If the deployment scan is not needed, you can avoid this behavior by removing the deployment-scanner subsystem instead of setting scanEnabled="false" : /subsystem=deployment-scanner:remove()

      Description

      Even if scanEnabled="false" is specified in the deployment-scanner subsystem, a deployment marker can be created for files located under the deployment-scanner directory. This happens when deploying an application which has the same filename to the file through the management CLI.

      This behavior did not happen in EAP 6.4.x, but this happens since EAP 7.x because of FileSystemDeploymentService#handleNotification() processing.

      I think this behavior itself does not have a negative effect, so this is a minor issue. However, it's better to avoid creating an unneeded marker file.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  ehugonnet Emmanuel Hugonnet
                  Reporter:
                  mmiura Masafumi Miura
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  1 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: