Community
Participate
Working Groups
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.
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.
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.
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
Created attachment 202455 [details] Final Patch Version
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
Code committed and released to R3_0_5_patches
