Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 323744

Summary: Classpath dependency enablement should directly control dynamic manifest updating
Product: [WebTools] WTP Java EE Tools Reporter: Jason Peterson <jasonpet>
Component: jst.j2eeAssignee: Jason Peterson <jasonpet>
Status: RESOLVED FIXED QA Contact: Chuck Bridgham <cbridgha>
Severity: normal    
Priority: P3 CC: ccc, jsholl
Version: 3.2Flags: jasonpet: pmc_approved? (david_williams)
jasonpet: pmc_approved? (raghunathan.srinivasan)
jasonpet: pmc_approved? (naci.dai)
deboer: pmc_approved+
jasonpet: pmc_approved? (neil.hauge)
jasonpet: pmc_approved? (kaloyan)
cbridgha: review+
Target Milestone: 3.2.2   
Hardware: PC   
OS: Windows XP   
Whiteboard: PMC_approved
Attachments:
Description Flags
patch
none
JUnit_patch none

Description Jason Peterson CLA 2010-08-26 14:56:10 EDT 
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.
Comment 1 Jason Peterson CLA 2010-08-30 16:53:50 EDT 
Created attachment 177787 [details]
patch
Comment 2 Jason Peterson CLA 2010-08-30 16:55:28 EDT 
Created attachment 177788 [details]
JUnit_patch
Comment 3 Chuck Bridgham CLA 2010-08-31 10:41:04 EDT 
approve
Comment 4 Jason Peterson CLA 2010-08-31 11:13:51 EDT 
    * 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.
Comment 5 Jason Sholl CLA 2010-08-31 13:44:34 EDT 
code checked into head for wtp 3.2.2 and 3.3