Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-6897

Replacing a disabled deployment destroys profile section of xml config

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 10.1.0.CR1, 10.1.0.Final
    • 10.0.0.Final
    • Server
    • None
    • Hide

      1. Unpack a fresh WildFly 10.0 Final app server
      2. Modify standalone.xml to bind management and public to <any-address/>. (May not be required in your environment)
      3. bin/add-user.sh and add management user
      4. Start WildFly (bin/standalone.sh)
      5. Log in to management console and add a new deployment. (I tested w/ the wildfly-helloworld.jar from the wildfly/quickstart repo on Github, last commit Jun 20)
      6. If you enabled deployment when creating it, disable it now.
      7. Make note of the size of the standalone.xml configuration file (~20k)
      8. Replace the deployment with the same .jar file
      9. Notice the size of the standalone.xml configuration file (~5k)

      Show
      1. Unpack a fresh WildFly 10.0 Final app server 2. Modify standalone.xml to bind management and public to <any-address/>. (May not be required in your environment) 3. bin/add-user.sh and add management user 4. Start WildFly (bin/standalone.sh) 5. Log in to management console and add a new deployment. (I tested w/ the wildfly-helloworld.jar from the wildfly/quickstart repo on Github, last commit Jun 20) 6. If you enabled deployment when creating it, disable it now. 7. Make note of the size of the standalone.xml configuration file (~20k) 8. Replace the deployment with the same .jar file 9. Notice the size of the standalone.xml configuration file (~5k)
    • Compatibility/Configuration

    Description

      When replacing a deployment that is disabled at the time of replacement, Wildfly will write out a new configuration .xml that is missing the entire <profile> section, resulting in an application server that is, essentially, non-functional once restarted. There is no obvious effect until restart.

      Also note there is a forum post reporting this behavior from April.

      Attachments

        Issue Links

          is caused by

          Bug - A problem that impairs or prevents the functions of the product. WFCORE-1577 After a full-replace-deployment operation a server on a hosts subsystem model is empty

          • Blocker - To be worked above all other priorities. This term is chosen when the severity of the issue is very high, has no workaround, or the effort for the change is comparatively low. Issues that may be very publicly visible and could generate significant media attention may also drive a higher priority.
          • Resolved
          is related to

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-6598 [GSS](7.1.0) Replacing a disabled deployment destroys profile section of xml config

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Verified

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-6599 [GSS](7.0.z) Replacing a disabled deployment destroys profile section of xml config

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Verified

          Activity

            People

              bstansbe@redhat.com Brian Stansberry
              bdaroz Brian Rozmierski (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: