Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 343562 - JEM needs to handle a flush better
Summary: JEM needs to handle a flush better
Status: RESOLVED FIXED
Alias: None
Product: WTP Java EE Tools
Classification: WebTools
Component: jst.jem (show other bugs)
Version: 1.5.5   Edit
Hardware: PC Windows XP
: P1 major (vote)
Target Milestone: 3.2.4   Edit
Assignee: Carl Anderson CLA
QA Contact: Chuck Bridgham CLA
URL:
Whiteboard: PMC_approved
Keywords:
Depends on: 343558
Blocks: 348396
  Show dependency tree
 
Reported: 2011-04-21 10:51 EDT by Carl Anderson CLA
Modified: 2011-06-06 14:09 EDT (History)
2 users (show)

See Also:
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+

Attachments
Keep the current Methods "valid" (2.66 KB, patch)
2011-04-22 11:10 EDT, Carl Anderson CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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