Community
Participate
Working Groups
An adopter product is seeing the NPE shown below. Looks like this is due to a null archive name for the IVirtualReference. public ChildModuleReference(IVirtualReference reference, IPath root) { . . . root.append(reference.getRuntimePath()).append(reference.getArchiveName()); } java.lang.NullPointerException at org.eclipse.core.runtime.Path.append(Unknown Source) at org.eclipse.wst.common.componentcore.internal.flat.ChildModuleReference.<init>(Unknown Source) at org.eclipse.wst.common.componentcore.internal.flat.FlatVirtualComponent.addUsedReferences(Unknown Source) at org.eclipse.wst.common.componentcore.internal.flat.FlatVirtualComponent.treeWalk(Unknown Source) at org.eclipse.wst.common.componentcore.internal.flat.FlatVirtualComponent.cacheResources(Unknown Source) at org.eclipse.wst.common.componentcore.internal.flat.FlatVirtualComponent.fetchResources(Unknown Source) at org.eclipse.jst.j2ee.internal.archive.operations.FlatComponentArchiver.saveArchive(Unknown Source)
Assigning to Rob for initial investigation. I see that other places in our code guard against a null archive name, but I am not sure if just a simple null check is the correct thing to do in this scenario.
In tonight's J2EE JUnit bucket run, I noticed that testMembersDeployment failed with exactly this problem.
A Nullcheck here probably would not be appropriate. There are two types of references, USED references and CONSUMED references. In an example where EarProject has a USES reference for WebProject, the web project's resources are published as: Blah.ear/WebProject.war/each/war/resource In an example where EarProject has a CONSUMES reference for WebProject, the behaviour is: Blah.ear/each/war/resource So as you can see, for all USES references, an archive name is a mandatory attribute. It'd be interesting to see why this unit test is failing, or why this particular reference has no archive name.
Retargeting, but, just wanted to say that, all USED references should have a non-null getName(). USED references require a name because their deploy path relative to the parent is parent.append(ref.moduleRelative).append(ref.getname()). This is by previous behaviour and the standardizations that came in with the addition of the Deployment Assembly page. Any time a USED reference has a null name, this is a bug and the causes of a null-named USED reference should be found, not guarded against.
Moving to 3.3.1
Jason: Were you able to verify this situation with your adopter product? Perhaps they were having an issue in that the name was null when it should not have been?
Moving to 3.4.1
I'm wondering if this is still an issue? component.xml files should not have references without explicitly setting an archiveName. Since this bug was from 2010, that may have been before such a requirement was made explicit...
Closing this. If the scenario can be reproduced, please reopen.
