Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-15999

[GSS](7.2.z) FileSystemDeploymentService#handleNotification() can create an unneeded deployment marker file even if scanEnabled="false" is specified

    XMLWordPrintable

Details

    • -
    • 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()
    • 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.

    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.

      Attachments

        Issue Links

          Activity

            People

              mstefank Martin Stefanko
              rhn-support-mmiura Masafumi Miura
              Daniel Cihak Daniel Cihak
              Daniel Cihak Daniel Cihak
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: