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
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)
What is the risk of fixing it? (Risk)
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?
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