Community
Participate
Working Groups
This is closely related to the problem described in bug 302260. Steps to reproduce: 1. Create new EAR 5.0 project. 2. Create new EJB 3.0 project, click "Add to EAR project" checkbox and choose the EAR from step 1. The result: a) The EJB 3.0 project is created together with a EJB Client project. This is as expected. b) The EJB Client project is added directly to the /lib folder of the EAR. c) A Class-path entry pointing to the EJB Client JAR is added to the Manifest of the EJB 3.0 project. b) and c) contradicts each other. According to the specification the generated class-path entry in the EJB's manifest tells the app server to look-up for the EJB Client JAR in the EAR's root. But the EJB Client JAR is not in the root, it is in the /lib folder. This problem fails the deployment on the SAP app server. It can be a problem for other vendors app server - it depends how they implement the spec. The workaround is to manually remove the problematic class-path entry.
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.
