Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 355244

Summary:

EAR5.0 Java EE Module Dependencies, selecting "In Lib Dir" deletes imported utility jar from workspace and it cause a NPE.

Product:

[WebTools] WTP Java EE Tools

Reporter:

Salvador Zalapa <zalapa>

Component:

jst.j2ee

Assignee:

Salvador Zalapa <zalapa>

Status:

RESOLVED FIXED

QA Contact:

Chuck Bridgham <cbridgha>

Severity:

normal

Priority:

CC:

ccc, shr31223

Version:

3.0.5

Flags:

cbridgha: review+
ccc: review+

Target Milestone:

3.0.5 P

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
First Version	none
Final Patch Version	shr31223: iplog+

Description Salvador Zalapa

2011-08-19 12:54:55 EDT

Build Identifier: wtp3.0.5

In the EAR5.0 Java EE Module Dependencies page when I check the "In Lib  Dir" option of an imported utility jar entry, it deletes physically the jar from workspace and a NPE is triggered.

Reproducible: Always

Steps to Reproduce:
1.- On an  EAR50 project  > Import J2EE Utilty jar , and select: "Copy Utilty jars into an exiting EAR from an external location".
and specify some external jar. As result, it is copied into EAR50/. 

2.- Launch EAR50 Java EE Module Dependencies,and  select  the "In Lib  Dir" column of the jar entry just imported, click Ok.

Comment 1 Salvador Zalapa

2011-08-19 13:15:20 EDT

When an entry is modified, (using the Java EE Module Dependencies page), it is removed and, then it is added back (modified). The thing is that the RemoveComponentFromEnterpriseApplicationOperation.execute(), calls to updateEARDD(monitor) method who removes physically the resource from the workspace, that's why the resource is deleted and the NPE is triggered. This behavior is valid when a project module is delete, but not when a jar from the same ear is edited to be placed in /lib folder. I propose a first version for the issue that consists in do not delete the resource if its project is the same EAR, this patch will not affect further configuration and is the less invasive i can see, since it is just a validation. Have a look to the patch.

Comment 2 Salvador Zalapa

2011-08-19 13:17:43 EDT

Created attachment 201818 [details]
First Version

This is the first version of the patch, notice that the drawback is that it will export duplicated jars.

Comment 3 Chuck Bridgham

2011-08-24 17:06:27 EDT

I don't love this solution, but it has minimal impact, and this code has completely changed in later versions...(without this issue)   I approve

Comment 4 Salvador Zalapa

2011-08-30 15:32:14 EDT

Created attachment 202455 [details]
Final Patch Version

Comment 5 Salvador Zalapa

2011-08-30 15:39:09 EDT

The first patch version end up with the same named jar in the root, and a jar with _1.jar in the lib dir when you export the EAR.

The thing is that the EARVitualComponent.getReferences()  method adds the dynamic references to the cache, and then when AddModulestoEARPropertiesPage.getURIMappingName()method gets the references it it will get all the stuff ( even the dynamic ones ) , so what I propose is:  to create a public method in order to  get only the hardReferences in the EARVirtualComponent class, and substitute  getReferences() for hardReferences ( ) inside getURIMappings(). Adding a second patch

Comment 6 Roberto Sanchez Herrera

2011-09-01 13:19:43 EDT

Code committed and released to R3_0_5_patches