Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 311208 - NPE protection required in VirtualComponent
Summary: NPE protection required in VirtualComponent
Status: RESOLVED FIXED
Alias: None
Product: WTP Java EE Tools
Classification: WebTools
Component: jst.j2ee (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: 3.2 RC1   Edit
Assignee: Jason Sholl CLA
QA Contact: Chuck Bridgham CLA
URL:
Whiteboard: PMC_approved
Keywords:
: 311732 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-04-30 12:35 EDT by Jason Sholl CLA
Modified: 2010-05-13 23:13 EDT (History)
4 users (show)

See Also:
david_williams: pmc_approved+
stryker: pmc_approved? (raghunathan.srinivasan)
stryker: pmc_approved? (naci.dai)
stryker: pmc_approved? (deboer)
stryker: pmc_approved? (neil.hauge)
stryker: pmc_approved? (kaloyan)
cbridgha: review+


Attachments
patch (1.39 KB, patch)
2010-04-30 12:38 EDT, Jason Sholl CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jason Sholl CLA 2010-04-30 12:35:54 EDT
The VirtualComponent needs to protect against NPEs by only customizing references that are correct.  This appears to be the result of a simple coding error (failing to include this line within the above null check).  This is causing adopter product failures due to NPEs.
Comment 1 Jason Sholl CLA 2010-04-30 12:38:18 EDT
Created attachment 166639 [details]
patch

Here's the NPE this is protecting against:

java.lang.NullPointerException
        at org.eclipse.wst.common.componentcore.internal.util.VirtualReferenceUtilities.getDefaultArchiveName(VirtualReferenceUtilities.java:71)
        at org.eclipse.wst.common.componentcore.internal.util.VirtualReferenceUtilities.ensureReferencesHaveNames(VirtualReferenceUtilities.java:60)
        at org.eclipse.jst.j2ee.componentcore.util.EARVirtualComponent.customizeCreatedReference(EARVirtualComponent.java:97)
        at org.eclipse.wst.common.componentcore.internal.resources.VirtualComponent.getReferences(VirtualComponent.java:396)
        at org.eclipse.jst.j2ee.componentcore.util.EARVirtualComponent.getHardReferences(EARVirtualComponent.java:86)
        at org.eclipse.jst.j2ee.componentcore.util.EARVirtualComponent.getReferences(EARVirtualComponent.java:180)
        at org.eclipse.jst.j2ee.project.EarUtilities.getComponentReferencesAsList(EarUtilities.java:129)
        at org.eclipse.jst.j2ee.project.EarUtilities.getComponentReferences(EarUtilities.java:113)
        at org.eclipse.jst.j2ee.project.EarUtilities.getJ2EEModuleReferences(EarUtilities.java:83)
Comment 2 Rob Stryker CLA 2010-05-03 04:03:56 EDT
I've glanced at it, looks good. Chuck?
Comment 3 Chuck Bridgham CLA 2010-05-04 15:01:36 EDT
approved
Comment 4 Rob Stryker CLA 2010-05-04 23:52:32 EDT
After M7 all require PMC approvals
Comment 5 Raghunathan Srinivasan CLA 2010-05-05 01:04:14 EDT
Please follow the process outlined on this wiki , http://wiki.eclipse.org/WTP_PMC_Defect_Review#How_To_Prepare_a_PMC_Defect_Candidate
Comment 6 Rob Stryker CLA 2010-05-05 08:42:01 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. 
    
This is an unexpected NPE which can blow away the stack. 

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

There is no workaround

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

Tested manually since it is merely a simple NPE

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

I have looked it over, and Chuck Bridgha has approved. The technical overview is to avoid the NPE and not call methods if a reference is null. 

    * What is the risk associated with this fix? 

I see miniscule to zero risk with this fix.
Comment 7 Jason Sholl CLA 2010-05-05 16:22:15 EDT
code checked into HEAD for RC1
Comment 8 Chuck Bridgham CLA 2010-05-05 20:31:47 EDT
*** Bug 311732 has been marked as a duplicate of this bug. ***