Bug 311620

Description Larry Isaacs 2010-05-04 16:10:51 EDT

Created attachment 167034 [details]
Patch to avoid NPE in equals() for VirtualReference with null archiveName

There are different ways for VirtualReference.equals() to get called, so it's hard to be specific about when the NPE can occur.  Here is one scenario that is reliable for me:

1. In a new workspace, create a Dynamic Web Project and a Utility Project.
2. In the Utility Project, go to the Libraries tab of Java Build Path page and
use the "Add Variable..." button to add JUNIT_HOME/junit.jar to the build path.
3. In the Dynamic Web Project, go to the Deployment Assembly page and click
Add.
3. Select "Referenced Projects Classpath Entries" and click Next.
4. Check the child jar of the Utility Project and click Finish. Note: Bug 311607 addresses why the jar name might not display properly.
5. In the Deployment Assembly page click Add again.
6. Select "Variable" and click Next, then select JUNIT_HOME/junit.jar and click Finish.  Note: For demonstrating the NPE, this second "inclusion" of junit.jar is okay.
7. In the Deployment Assembly page select the newly added JUNIT_HOME/junit.jar and click Remove.

For me, this results in:

java.lang.NullPointerException
at org.eclipse.wst.common.componentcore.internal.resources.VirtualReference.equals(VirtualReference.java:165)
at org.eclipse.jface.viewers.StructuredViewer.equals(StructuredViewer.java:706)
...

The problem is that the VirtualReference for the "Pull in classpath elements from referenced projects" entry returns null for getArchiveName().  The attached patch protects against the NPE.  It does not bother to include the new "isDerived" property in the comparison.  I don't know if it would make sense for all the other properties to be equal and only "isDerived" be different.  If this is possible, then it should be included in the equals() comparison.