Community
Participate
Working Groups
Classpath dependency enablement has always meant to control whether dynamic manifest updates would occur at export and runtime. When set to false these dynamic updates will not occur because no resources requiring a dynamic manifest update would be returned. The enablement was directly controlling the list of resources, which indirectly determined whether the manifest should be updated at runtime. This was easy to do pre-EE5 since all classpath dependency entries outside of web project entries required the manifest to be updated. However, in EE5 and above, entries that map to the EAR's lib folder do not require the manifest to be dynamically updated. The code was recently updated in bug 323176 to make light of the EE5 and above case. However, this is really too hard to solve since we have no way to determine whether the module is mapping to a legacy EAR or not in the current context. The right way to solve this is to have the dependency enablement directly control the updating of the manifest (resources list will always contain all classpath dependencies). When on, the default, it will always update the manifest for any entries that map to the parent container. When false, it will never dynamically update the manifest.
Created attachment 177787 [details] patch
Created attachment 177788 [details] JUnit_patch
approve
* 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. The dynamic updating of the manifest breaks single-root for some servers, which hurts performance. Need to give adopters the option to change the default behavior for doing dynamic manifest updates. By default, the dynamic update is done. However, an adopter may want to set this to false so the dynamic update is not done at runtime. The update could then be done at development time. * 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? JUnit testcase is attached. I have updated some existing classpath dependency tests to honor the ClasspathEnablement flag. * Give a brief technical overview. Who has reviewed this fix? The dependency enablement will directly control the updating of the manifest. When true, the default, it will always update the manifest for any entries that map to the parent container. When false, it will never dynamically update the manifest. Chuck has reviewed this fix. * What is the risk associated with this fix? minimal - fix only pertains to scenario where ClasspathEnablement is set to false. This can only be done via API in WTP.
code checked into head for wtp 3.2.2 and 3.3
