Bug 343562

Summary: JEM needs to handle a flush better
Product: [WebTools] WTP Java EE Tools Reporter: Carl Anderson <ccc>
Component: jst.jemAssignee: Carl Anderson <ccc>
Status: RESOLVED FIXED QA Contact: Chuck Bridgham <cbridgha>
Severity: major    
Priority: P1 CC: david_williams, kaloyan
Version: 1.5.5Flags: david_williams: pmc_approved+
ccc: pmc_approved? (raghunathan.srinivasan)
ccc: pmc_approved? (naci.dai)
ccc: pmc_approved? (deboer)
ccc: pmc_approved? (neil.hauge)
kaloyan: pmc_approved+
ccc: pmc_approved? (cbridgha)
cbridgha: review+
Target Milestone: 3.2.4   
Hardware: PC   
OS: Windows XP   
Whiteboard: PMC_approved
Bug Depends on: 343558    
Bug Blocks: 348396    
Attachments:
Description Flags
Keep the current Methods "valid" none

Description Carl Anderson CLA 2011-04-21 10:51:33 EDT 
This fix needs to get into the active development streams - R3_2_maintenance and HEAD.

+++ This bug was initially created as a clone of Bug #343558 +++

Currently, if JEM is gathering (or has gathered) the Methods from a (JEM) JavaClass, and a flush() occurs, the Methods are removed from their parents and are invalid, resulting in NPEs and other errors without any warning.

There are things we can do, such as replacing the parent JavaClass with a JavaClassRef, that will at least keep the current Methods useful, while still allowing the flush to proceed.
Comment 1 Carl Anderson CLA 2011-04-21 10:53:34 EDT 
This is causing (intermittent) major problems, including unnecessary
termination, of various "headless" utilities based on WTP.
The adopter (IBM) is requesting that this fix be propagated to all active versions of WTP.
Comment 2 Carl Anderson CLA 2011-04-22 11:10:40 EDT 
Created attachment 193917 [details]
Keep the current Methods "valid"
Comment 3 Chuck Bridgham CLA 2011-04-22 15:28:17 EDT 
approved
Comment 4 Carl Anderson CLA 2011-04-22 17:52:43 EDT 
Committed to HEAD for WTP 3.3 M7
Comment 5 Carl Anderson CLA 2011-04-22 18:20:33 EDT 
Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such.

When a flush occurs while Methods are being accessed, the Methods become "invalid" without warning, causing various exceptions and other problems.  In headless tooling, there is no way to recover from this, and thus the tools will fail.  IBM is requesting that this be fixed.

Is there a work-around? If so, why do you believe the work-around is insufficient?

There is no simple work-around.

How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added?

This fix was tested both via running the Java EE JUnit bucket and by providing a patch to adopters/customers that were encountering this problem utilizing tools based on WTP in a headless environment.  This fix resolved their issues.

Give a brief technical overview. Who has reviewed this fix?

Chuck Bridgham has reviewed the fix.  Simply put, instead of setting the container to null, this fix now puts in a JavaClassRef as the container, so that future queries to this Method still provide the current information, yet the reference from the JavaClass is still removed, allowing the Method to be garbage-collected as soon as no external reference exists.

What is the risk associated with this fix?

This is a low risk fix.
Comment 6 David Williams CLA 2011-04-25 23:35:09 EDT 
Sounds important, and in need of lots of testing ... which I assume has already happened. 

Thanks!
Comment 7 Carl Anderson CLA 2011-04-27 21:13:13 EDT 
Committed to R3_2_maintenance for WTP 3.2.4