Community
Participate
Working Groups
Created attachment 174344 [details] patch An adopter product has created their own module delegate for a Java EE utility project. In this case the project is a simple PDE project. As a result two different module delegates are created. Currently, the FlatComponentDeployable code just chooses the first one when multiple exist. Usually, only one would exist because delegate creation is based on the component. It is a J2EEModuleVirtualComponent in this case. The solution is to create a new method that extenders can override to specify a preferred delegate. The default would be to continue to return the first one found.
Created attachment 174345 [details] updated_patch
* 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. A scenario has been found where two different module delegates are created for the same component. The current code just chooses the first delegate found. * Is there a work-around? If so, why do you believe the work-around is insufficient? No workaround exists * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Fix has been tested in the UI. * Give a brief technical overview. Who has reviewed this fix? A new method was created that extenders can override if they wish to control which delegate is returned. The default is still to return the first found. Chuck has reviewed this fix. * What is the risk associated with this fix? minimal - the default behavior still exists for any extenders that do not override the new method.
approved - Additive api for extenders only. default behavior still applies
+1. Agreed, picking the 'first' module is inherently broken and will eventually cause problems as it has here. You may want to think about whether there is some default behaviour that the JEE components should be doing in WTP in the future, e.g. filtering by module type.
I'm fine approving this, since sounds important for adopter, but ... you are saying adopter has to extend org.eclipse.wst.web.internal.deployables.FlatComponentDeployable right? From the package name, doesn't sound like an API. Is it? One of those APIs that has "internal" in the name? Thanks,
Created attachment 174407 [details] j2ee plugin now requires a newer wst.web plugin One minor (but important) additional change- we need to raise the org.eclipse.jst.j2ee prereq of org.eclipse.wst.web, since it calls/overrides the method added there.
Committed to HEAD for WTP 3.2.1 and WTP 3.3 Unfortunately, I was reviewing another bug, and copied the header for that bug, so the commit comment was: [319935] Null Pointer Exception when Importing UtilityJar
