Community
Participate
Working Groups
Created attachment 167342 [details] patch An adopter ran into a scenario where they had added the EAR library to an EAR project as a Classpath Container reference from the Deployment Assembly editor. Everything appeared OK until they restarted the workspace and got the following npe thrown to the log (close/reopen will also trigger the npe): java.lang.NullPointerException at org.eclipse.jst.common.internal.modulecore.ClasspathContainerVirtualComponent.<init>(ClasspathContainerVirtualComponent.java:48) at org.eclipse.jst.common.internal.modulecore.ClasspathContainerReferenceResolver.resolve(ClasspathContainerReferenceResolver.java:43) . . The fix is to simply and safely check for null to avoid the npe from being thrown.
Created attachment 167434 [details] Allows for re-fetching later There is a bit of uncertainty as to exactly how long virtual components stick around, at least for me, and because of this I think it's a bit irresponsible to definitely assign the member variable an empty array. If these objects stick around very long, when the container does exist, this component may still be returning the empty array. So with that in mind, I've attached a different patch which can re-check on occasion.
Rob, your latest patch does not apply cleanly- ClasspathContainerVirtualComponent was updated on 5/5. Can you please update your patch?
Created attachment 168069 [details] Applies cleanly
Created attachment 168206 [details] move the check for a null containerEntries into loadContainerEntries()
looks good, push through for approvals now
After a lot of discussion about this bug, here is what I, as the component lead, have decided: We have some great ideas on how to improve our handling of containerEntries within a ClasspathContainerVirtualComponent. However, we are in RC1, and as such simple, safe fixes are preferable. I opened bug 312678 to allow us to address a more thorough solution for this long term. Short term, let's go with the original patch that Jason Peterson attached.
I approve of the original patch.
* 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. On workspace restart a NPE is thrown to log and user is unable to open the deployment assembly page for the EAR in which the user had added the EAR library. * Is there a work-around? If so, why do you believe the work-around is insufficient? The workaround is to manually edit the component file to remove the container. This is very inefficient for the user. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? No unit tests for this bug. * Give a brief technical overview. Who has reviewed this fix? The fix is to simply and safely check for null to avoid the npe from being thrown. This has been reviewed and approved by Carl Anderson. Jason Sholl and Rob Stryker have reviewed it as well. * What is the risk associated with this fix? I see little risk with this patch
code checked into head for WTP 3.2 RC1
*** Bug 312678 has been marked as a duplicate of this bug. ***
