Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #319439 +++ The EAR Validator is throwing exceptions when its module projects are closed. Here is an example of the exceptions: org.eclipse.jst.j2ee.commonarchivecore.internal.exception.ArchiveWrappedException Stack trace of nested exception: org.eclipse.jst.j2ee.commonarchivecore.internal.exception.NoModuleFileException: A file does not exist for module element having uri: EAR14Client.jar at org.eclipse.jst.j2ee.commonarchivecore.internal.impl.ModuleRefImpl.checkType(ModuleRefImpl.java:497) at org.eclipse.jst.j2ee.commonarchivecore.internal.impl.ModuleRefImpl.initModuleFileFromEAR(ModuleRefImpl.java:128) at org.eclipse.jst.j2ee.commonarchivecore.internal.impl.ModuleRefImpl.getModuleFile(ModuleRefImpl.java:106) at org.eclipse.jst.j2ee.commonarchivecore.internal.impl.EARFileImpl.getModuleFile(EARFileImpl.java:93) at org.eclipse.jst.j2ee.commonarchivecore.internal.impl.EARFileImpl.getDeploymentDescriptor(EARFileImpl.java:333) at org.eclipse.jst.j2ee.commonarchivecore.internal.impl.ModuleRefImpl.getDeploymentDescriptor(ModuleRefImpl.java:165) at org.eclipse.jst.j2ee.model.internal.validation.EarValidator.clearUpSubTaskMessageDestinationMessages(EarValidator.java:838) at org.eclipse.jst.j2ee.model.internal.validation.EarValidator.validateMessageDestinationRefs(EarValidator.java:811) at org.eclipse.jst.j2ee.model.internal.validation.EarValidator.validateMessageDestinationRefs(EarValidator.java:803) at org.eclipse.jst.j2ee.model.internal.validation.EarValidator.validateMessageDestinations(EarValidator.java:748) at org.eclipse.jst.j2ee.model.internal.validation.EarValidator.validate(EarValidator.java:125) at org.eclipse.jst.j2ee.model.internal.validation.EarValidator.validateInJob(EarValidator.java:144) at org.eclipse.jst.j2ee.internal.validation.UIEarValidator.validateInJob(UIEarValidator.java:276) at org.eclipse.wst.validation.internal.operations.ValidatorJob.run(ValidatorJob.java:78) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) org.eclipse.jst.j2ee.commonarchivecore.internal.exception.ArchiveWrappedException Stack trace of nested exception: org.eclipse.jst.j2ee.commonarchivecore.internal.exception.NoModuleFileException: A file does not exist for module element having uri: EAR14EJB.jar at org.eclipse.jst.j2ee.commonarchivecore.internal.impl.ModuleRefImpl.checkType(ModuleRefImpl.java:497) at org.eclipse.jst.j2ee.commonarchivecore.internal.impl.ModuleRefImpl.initModuleFileFromEAR(ModuleRefImpl.java:128) at org.eclipse.jst.j2ee.commonarchivecore.internal.impl.ModuleRefImpl.getModuleFile(ModuleRefImpl.java:106) at org.eclipse.jst.j2ee.commonarchivecore.internal.impl.EARFileImpl.getModuleFile(EARFileImpl.java:93) at org.eclipse.jst.j2ee.commonarchivecore.internal.impl.EARFileImpl.getDeploymentDescriptor(EARFileImpl.java:333) at org.eclipse.jst.j2ee.commonarchivecore.internal.impl.ModuleRefImpl.getDeploymentDescriptor(ModuleRefImpl.java:165) at org.eclipse.jst.j2ee.model.internal.validation.EarValidator.clearUpSubTaskMessageDestinationMessages(EarValidator.java:838) at org.eclipse.jst.j2ee.model.internal.validation.EarValidator.validateMessageDestinationRefs(EarValidator.java:811) at org.eclipse.jst.j2ee.model.internal.validation.EarValidator.validateMessageDestinationRefs(EarValidator.java:803) at org.eclipse.jst.j2ee.model.internal.validation.EarValidator.validateMessageDestinations(EarValidator.java:748) at org.eclipse.jst.j2ee.model.internal.validation.EarValidator.validate(EarValidator.java:125) at org.eclipse.jst.j2ee.model.internal.validation.EarValidator.validateInJob(EarValidator.java:144) at org.eclipse.jst.j2ee.internal.validation.UIEarValidator.validateInJob(UIEarValidator.java:276) at org.eclipse.wst.validation.internal.operations.ValidatorJob.run(ValidatorJob.java:78) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Created attachment 173929 [details] patch for 3.2.1
approved.. cleaning up unwanted log errors... and this is a valid case for cleanup
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. Customers are seeing these unnecessary log messages and are under the impression that something is wrong with their workspace. * Is there a work-around? If so, why do you believe the work-around is insufficient? No * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Tested with UI. * Give a brief technical overview. Who has reviewed this fix? In this case the NoModuleFileException exception should simply be caught and eaten rather than logged. * What is the risk associated with this fix? None.
code checked into HEAD for WTP 3.2.1
