Bugzilla – Full Text Bug Listing
| Summary: | [API] Problematic Class-Path entry generated in EJB 3.0's Manifest | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Java EE Tools | Reporter: | Kaloyan Raev <kaloyan> | ||||||
| Component: | jst.j2ee | Assignee: | Chuck Bridgham <cbridgha> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Chuck Bridgham <cbridgha> | ||||||
| Severity: | major | ||||||||
| Priority: | P3 | CC: | ccc, david_williams, jsholl | ||||||
| Version: | 3.2 | Flags: | david_williams:
pmc_approved+
cbridgha: pmc_approved? (raghunathan.srinivasan) cbridgha: pmc_approved? (naci.dai) deboer: pmc_approved+ cbridgha: pmc_approved? (neil.hauge) cbridgha: pmc_approved? (kaloyan) ccc: review+ jsholl: review+ |
||||||
| Target Milestone: | 3.2.1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows Vista | ||||||||
| Whiteboard: | PMC_approved | ||||||||
| Attachments: |
|
||||||||
|
Description
Kaloyan Raev
Assigning to Chuck for initial investigation. This appears to be a bad problem, so I am targetting it to WTP 3.2.1, even though it is quite late- please retarget as appropriate. Yes we are aware of this issue, and although I'm not completely confident on spec verbage... Is the uri relative to the EJB jar? or contains the full Ear uri.. In any case, we will look at reverting the placement of the ejb client jar in the lib folder. After investigating this.. we are actually going to revert the change where we are placing the EJB Client jar's by default. Reasons are... 1) The <ejb-client-jar> entry in the ejb DD is a uri of the client jar, and is relative to the EJB module, which is placed in the root of the Ear. This uri would need to change to "/lib/client.jar" 2) changing it back to the root location would eliminate the need to change the Add To Ear operation for client jar's preparing a patch now, if you don't agree with this action - let me know Created attachment 174229 [details]
patch
(In reply to comment #4) > Created an attachment (id=174229) [details] > patch I had to create a new utility to find the client projects, and make sure we differ the behavior. I approve of this change. I am marking this with API because we are adding two new static methods to the EJBUtilities class (which is public API) - 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. By default, the lib location for EJB client jar's causes issues related to MANIFEST and uri embedded inside the EJB deployment descriptor - Is there a work-around? If so, why do you believe the work-around is insufficient? Yes, but sloppy, and will confuse users - classpath/deploy issues will result - How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Using our existing test suite, and I tweaked it to match the DD uri with actual deploy location - Give a brief technical overview. Who has reviewed this fix? Carl and Jason reviewed. Fix was to revert the behavior for EJB client projects, placing it in the Ear root aside the EJB module - What is the risk associated with this fix? Low risk - tested code checked into head for wtp 3.2.1 Created attachment 174448 [details]
patch for 3.2.1
Fixes a NPE that was being thrown if an EJB project did not have an associated EJB client project.
the last patch has also been checked in. |