Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 322678 - In EARVirtualComponent.getHardReferences, need to get the archiveName directly from the referencedComponent, instead of getting it from the dependentObject
Summary: In EARVirtualComponent.getHardReferences, need to get the archiveName directl...
Status: RESOLVED FIXED
Alias: None
Product: WTP Java EE Tools
Classification: WebTools
Component: jst.j2ee (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.0.5 P   Edit
Assignee: Hari Shankar CLA
QA Contact: Chuck Bridgham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-13 13:28 EDT by Hari Shankar CLA
Modified: 2010-08-30 17:47 EDT (History)
1 user (show)

See Also:
cbridgha: review+

Attachments
patch (3.45 KB, patch)
2010-08-13 13:29 EDT, Hari Shankar CLA 		ccc: iplog+
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 Hari Shankar CLA 2010-08-13 13:28:22 EDT 
Build Identifier: 305p

The EARVirtualComponent uses the dependentObject on a ReferencedComponent in order to get to the URI. We need to move away from this, since the dependentComponent is often stale if the uri changes.

Reproducible: Always
Comment 1 Hari Shankar CLA 2010-08-13 13:29:12 EDT 
Created attachment 176572 [details]
patch

This patch removes the use of dependentObject, and directly gets the archive name from the referencedcomponent. If the archive name is not found, we follow the currently existing default name logic.
Comment 2 Hari Shankar CLA 2010-08-16 10:51:06 EDT 
Some more additional information on this patch:

The getHardReferences() method only returns an arraylist of IVirtualReference objects, hence it is not concerned with matching the specific reference from the component file with the corresponding entry in the module.

Getting the archiveName from the dependentObject resulted in getting back stale values (we have seen this issue in other places as well), hence the decision not to get the archiveName from the dependentObject.

I realize that the earlier title conveyed a scope much larger and unintended to be covered by this defect, hence changed the title as well.

Requesting review of the patch.
Comment 3 Chuck Bridgham CLA 2010-08-18 13:24:54 EDT 
approved
Comment 4 Carl Anderson CLA 2010-08-30 17:46:34 EDT 
Committed to R3_0_5_patches