glassfish
  1. glassfish
  2. GLASSFISH-15963

.reload dynamic reload feature fails and destroys application directory

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 3.1_b41
    • Fix Version/s: 3.1_b42
    • Component/s: deployment
    • Labels:
      None

      Description

      A long-standing feature is that users can place individual updated files of an app directly into the correct location within the deployed applications/(appName) directory and then use

      touch applications/(appName)/.reload

      to trigger an automatic reload of the app.

      This feature is broken in the current 3.1 builds in a way that not only does not work but also deletes the expanded application directory.

      How bad is its impact? (Severity)
      Identify why the fix needs to occur now:

      • Is a regression of functionality or performance available in a prior release
      • Introduces an incompatibility
      • Likely to generate a customer support call
      • An in-your-face issue that will touch the majority of users

      How often does it happen? (Frequency)
      any time a user tries to use the "touch .reload" feature

      How much effort is required to fix it? (Cost)
      one-line change

      What is the risk of fixing it? (Risk)
      very low

      Does a work around for the issue exist? Can the workaround be reasonably employed by the end user?
      redeploying the whole application is a poor workaround; the point of the .reload feature is to allow "surgical" updates to selected files rather than redeploying the entire app

      If the issue is not fixed should the issue and its workaround (if applicable) be described in the Release Notes?
      yes

      How long has the bug existed in the product?
      rev 36941 (May 13, 2010)

      Do regression tests exist for this issue?
      no - adding one for this

      Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
      an archive deployment, with and without upload

      When will a tested fix be ready for integration?
      later today - fix is already implemented and is undergoing tests now

        Activity

        Hide
        Tim Quinn added a comment -

        taking ownership

        Show
        Tim Quinn added a comment - taking ownership
        Hide
        Nazrul added a comment -

        Approved for check in into RC3 pending the following activities:
        1) Code review
        2) All deployment dev tests pass
        3) Dev Test(s) for this feature is added and pass

        Show
        Nazrul added a comment - Approved for check in into RC3 pending the following activities: 1) Code review 2) All deployment dev tests pass 3) Dev Test(s) for this feature is added and pass
        Hide
        Tim Quinn added a comment -

        Fix checked in.

        Project: glassfish
        Repository: svn
        Revision: 45067 (3.1 branch) / 45068 (trunk)
        Author: tjquinn
        Date: 2011-02-11 22:59:25 UTC
        Link:

        Log Message:
        ------------
        Fix for 15963

        Work done earlier to help optimize synchronization of uploaded archives to remote instances introduced a bug which broke the .reload feature. Files uploaded during deployment are placed into a temporary directory under the domain's applications directory. The code at fault incorrectly assumed that a file anywhere under the domain's applications directory was an uploaded file. Deployment expands all archives and, except for the sync feature, the uploaded archive is no longer needed. So the code moved what it thought was the uploaded file to a separate directory for use by synchronization. But when a user touches the .reload file in the applications/(appName) directory for an already-deployed app, that directory is within the applications directory so this logic was moving the expanded directory to this separate directory, causing rather some havoc.

        This change repairs the problem by not moving a file under the applications directory if it is itself a directory. This is the lowest-risk fix at this point in 3.1.

        Approved: Nazrul
        Reviewed: Hong
        Tests: QL, deployment devtests including a new test for the .reload feature

        Revisions:
        ----------
        45067 (for 3.1 branch)
        45068 (for trunk)

        Modified Paths:
        ---------------
        branches/3.1/deployment/admin/src/main/java/org/glassfish/deployment/admin/DeployCommand.java

        Show
        Tim Quinn added a comment - Fix checked in. Project: glassfish Repository: svn Revision: 45067 (3.1 branch) / 45068 (trunk) Author: tjquinn Date: 2011-02-11 22:59:25 UTC Link: Log Message: ------------ Fix for 15963 Work done earlier to help optimize synchronization of uploaded archives to remote instances introduced a bug which broke the .reload feature. Files uploaded during deployment are placed into a temporary directory under the domain's applications directory. The code at fault incorrectly assumed that a file anywhere under the domain's applications directory was an uploaded file. Deployment expands all archives and, except for the sync feature, the uploaded archive is no longer needed. So the code moved what it thought was the uploaded file to a separate directory for use by synchronization. But when a user touches the .reload file in the applications/(appName) directory for an already-deployed app, that directory is within the applications directory so this logic was moving the expanded directory to this separate directory, causing rather some havoc. This change repairs the problem by not moving a file under the applications directory if it is itself a directory. This is the lowest-risk fix at this point in 3.1. Approved: Nazrul Reviewed: Hong Tests: QL, deployment devtests including a new test for the .reload feature Revisions: ---------- 45067 (for 3.1 branch) 45068 (for trunk) Modified Paths: --------------- branches/3.1/deployment/admin/src/main/java/org/glassfish/deployment/admin/DeployCommand.java

          People

          • Assignee:
            Tim Quinn
            Reporter:
            Tim Quinn
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Due:
              Created:
              Updated:
              Resolved: