Bug 311733

Comment 1 Larry Isaacs 2010-05-05 10:27:20 EDT

Accidentally submitted before it was ready.  Will fix after a meeting I have now.

Comment 2 Larry Isaacs 2010-05-05 11:22:54 EDT

Here is the originally planned Description.

The following scenario is not working for me with WTP 3.2M7:

1. Create a dynamic web project and a utility project, then reference the utility project from the web project.
2. Add an external jar on the Libraries tab of the Java Build Path in the utility project.
3. Use Quick Fix to mark the jar for "publish/export".
4. Publish the web project to a Tomcat server or export as a war file.

For publishing and exporting, the external jar is not included in the web application.  Only the utility project is included as a jar.  I'm not sure if I need to be doing something differently, or what WTP classes are now responsible for including such a jar in the web application.  It might be that Bug 311598 could be expanded to address more that just classpath containers.  I'm not familiar enough with the classes involved to offer a patch at this point.

Comment 3 Carl Anderson 2010-05-05 20:30:39 EDT

Assigning to Rob for initial investigation.

Comment 4 Rob Stryker 2010-05-07 05:00:14 EDT

Seems the bug here is that J2EEModuleVirtualComponent is not marked as implementing IClasspathDependencyReceiver.  This means it cannot receive such additions.

The fix is to implement the interface and the two methods in J2EEModuleVirtualComponent. A question is whether other users of J2EEModuleVirtualComponent (ejb projects, etc) should be expected to also be receivers or not? 

For now I'll be attaching a patch which implements the behaviour only in web projects (the ear case is already taken care of).

Comment 5 Rob Stryker 2010-05-07 05:02:36 EDT

Created attachment 167448 [details]
Implements the interface, framework now uses one of the methods

Comment 6 Rob Stryker 2010-05-07 05:04:46 EDT

Created attachment 167449 [details]
Implements the interface, framework now uses one of the methods (null-safe)

Comment 7 Rob Stryker 2010-05-07 05:05:38 EDT

The addition of the if-statement now requires carl's approval as well... =/

Comment 8 Chuck Bridgham 2010-05-10 14:48:45 EDT

approved

Comment 9 Carl Anderson 2010-05-11 11:11:02 EDT

Approved

Comment 10 Rob Stryker 2010-05-11 21:33:02 EDT

    * Explain why you believe this is a stop-ship defect. 
- This is a regression noticed by an adopter (tomcat) and their server adapter through a change in behaviour

    * Is there a work-around? If so, why do you believe the work-around is insufficient? 
- There are several workarounds, such as copying the jar directly into a project or adding it to the deployment via some other method, but the current change in behaviour breaks user expectations of past use cases

    * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? 
- I have tested this by hand. Dynamic web projects may now receive utility project's properly-marked classpath jars

    * Give a brief technical overview. Who has reviewed this fix? 
- The J2EEModuleVirtualComponent represents several different types of projects. In this patch, we add the interface to allow nesting of dependent project's marked classpath entries but enable it only for dynamic web projects, which is the scope of this bug and the broken past use-case. If other projects such as EJB would like this behaviour, this would be an enhancement and must be requested as such. 

    * What is the risk associated with this fix? 
I see the risk as small, as the interface is not heavily used in the codebase and a method ensures it is only re-enabled for dynamic web projects. 

PMC

Comment 11 Rob Stryker 2010-05-12 11:38:47 EDT

It seems JSholl committed half of this, so i've committed the missing changes to AddClasspathLibReferencesParticipant

Comment 12 Larry Isaacs 2010-05-13 09:38:10 EDT

Verified the jars are now published and exported using WTP I-3.2.0-20100513045407 build.