Community
Participate
Working Groups
Build Identifier: WTP 3.2.1 An adopter is seeing the following exception: java.lang.ClassCastException: org.eclipse.jst.j2ee.application.internal.impl.ApplicationImpl incompatible with org.eclipse.jst.javaee.application.Application at org.eclipse.jst.j2ee.internal.ui.preferences.EarModuleDependenciesPropertyPage.loadLibDirString(EarModuleDependenciesPropertyPage.java:80) at org.eclipse.jst.j2ee.internal.ui.preferences.EarModuleDependenciesPropertyPage.addLibDirComposite(EarModuleDependenciesPropertyPage.java:88) at org.eclipse.jst.j2ee.internal.ui.preferences.EarModuleDependenciesPropertyPage.createTableComposite(EarModuleDependenciesPropertyPage.java:76) at org.eclipse.wst.common.componentcore.ui.propertypage.AddModuleDependenciesPropertiesPage.createListGroup(AddModuleDependenciesPropertiesPage.java:214) at org.eclipse.wst.common.componentcore.ui.propertypage.AddModuleDependenciesPropertiesPage.createContents(AddModuleDependenciesPropertiesPage.java:184) at org.eclipse.jst.j2ee.internal.ui.preferences.EarModuleDependencyPageProvider.createRootControl(EarModuleDependencyPageProvider.java:40) Reproducible: Always
Created attachment 174840 [details] Proposed Patch Problem was caused since at some locations in the code, when getting the EAR library directory folder only the Java EE facet was being verified to be EE5 or above. Code has been updated to use the EarUtilities.getEARLibDir() method which considers both facet and DD version when calculating the EAR library directory folder. Corrected same issue at multiple locations in the code where same exception was seen because of same issue.
This patch also fixes the issue that when an EAR project has an EE 5.0 facet and an EE 1.4 DD, then the EAR library directory should not be available since modifying it would add a library-directory entry to the EE 1.4 DD (which is not valid). This fix updates code so that unless both the java facet and the DD are EE5 or above, the EAR library directory field is not shown and the Manifest Entries tab does not filter the jars in the /lib folder.
approved
* 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. An adopter gets a ClassCastException which is caused because at some locations in the code when getting the EAR library directory folder only the Java EE facet is being verified to be EE5 or above and the DD version is not verified. This patch also fixes the issue that when an EAR project has an EE 5.0 facet and an EE 1.4 DD, then the EAR library directory should not be available since modifying it would add a library-directory entry to the EE 1.4 DD (which is not valid). * 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 through UI. * Give a brief technical overview. Who has reviewed this fix? Code has been updated to use the EarUtilities.getEARLibDir() method which considers both facet and DD version when calculating the EAR library directory folder. Corrected same issue at multiple locations in the code. This fix updates code so that unless both the java facet and the DD are EE5 or above, the EAR library directory field is not shown and the Manifest Entries tab does not filter the jars in the /lib folder. Chuck Bridgham reviewed this patch. * What is the risk associated with this fix? Low.
Is this a regression from 3.2.0? Or from 3.1.2?
Oh, and I think this is sort of "two bugs in one", right? Perhaps it'd be clearer if title changed to "ClassCastException and EAR library directory displayed when it should not be"? (If I'm reading this right).
This defect is a regression from 3.1.x. When setting of Ear lib folder in previous releases, no exception was thrown.
For the record, I ran the Java EE Tools JUnit bucket against this patch, and it ran successfully.
Committed to HEAD for WTP 3.3. (And tentatively WTP 3.2.1, assuming PMC approval)
