Description Carl Anderson 2010-05-12 14:03:29 EDT

This clone is created to handle post-3.2 work to address this issue.

Things to consider:

If ClasspathContainerVirtualComponent instances are not short-lived, then we should re-get the container every time, and then worry about its classpath entries.  (According to Jason Sholl, a container's entries are computed once and cached.  If there is twiddling done on the component, JDT will create a new container instance for that project.)

JDT JavaDoc for IClasspathContainer.getClasspathEntries() states:

* This method must not be called by other clients.

However, we are calling it (and since we are not JDT, perhaps we are messing something up).

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

Created an attachment (id=167342)
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.