Bugs item #784584, was opened at 2003-08-07 08:08 Message generated for change (Comment added) made by frodeo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=784584&group_id=22866
Category: JBossWeb Group: v3.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Brian Stansberry (bstansberry) Assigned to: Scott M Stark (starksm) Summary: Class-Path entry in war manifest ignored Initial Comment: JBoss 3.2.2RC2, with either Tomcat or Jetty, appears to ignore the Class-Path header in a war's Manifest.mf file. If an EAR includes a library jar that is only referenced via a war's Class-Path header, the jar is not loaded and the war will fail with ClassNotFoundExceptions. It appears the Class-Path header in an EJB jar is handled properly. Attached is a test case that demonstrates this. The attached zip includes an EAR, along with the source and Ant script to build the ear. The ear includes two trivial wars, each of which has a manifest Class-Path header pointing to its respective library jar. Each library jar includes a trivial ServletContextListener implementation that will be invoked when the war is loaded. There is also a trivial EJB. The ejb jar's manifest includes a Class-Path entry pointing to one of the library jar's. The EJB does not actually use the library; I just included the Class-Path entry to test if JBoss loads the jar based on the EJB's manifest. One of the wars has a web.xml reference to the EJB. The EJB is not really used by the war; the web.xml reference is just there to ensure the EJB is loaded before the war. The war associated with the EJB will load properly; the other war will fail with a ClassNotFoundException when the web container attempts to instantiate the ServletContextListener. In 3.2.1, both wars load properly. ---------------------------------------------------------------------- Comment By: Frode Oldervoll (frodeo) Date: 2003-10-22 01:10 Message: Logged In: YES user_id=620986 Is this bug really fixed? I still have these problems in the 3.2.2 release. ---------------------------------------------------------------------- Comment By: Scott M Stark (starksm) Date: 2003-08-24 13:31 Message: Logged In: YES user_id=175228 The patch has been applied and a testcase added for the 3.2.2RC3 release. ---------------------------------------------------------------------- Comment By: Brian Stansberry (bstansberry) Date: 2003-08-12 03:29 Message: Logged In: YES user_id=695688 Patch posted in the SourceForge patch section ---------------------------------------------------------------------- Comment By: Barney Rubble (verilet) Date: 2003-08-12 02:29 Message: Logged In: YES user_id=679243 Yep, have the same problem. An EAR that works on 3.0.X and 3.2.1 and fails on anything with a 3.2.2. Jasper fails to locate beans referenced from the war's JSP pages. ---------------------------------------------------------------------- Comment By: Scott M Stark (starksm) Date: 2003-08-09 05:24 Message: Logged In: YES user_id=175228 I suspected it was the unpackwars feature. If having JarUtils create a manifest actually works that would be the preferred approach. ---------------------------------------------------------------------- Comment By: Brian Stansberry (bstansberry) Date: 2003-08-09 04:34 Message: Logged In: YES user_id=695688 I've traced this problem to the new UnpackWars behavior in AbstractWebContainer, which occurs by default in 3.2.2. The problem is when the war is unpacked, the MANIFEST.MF file is not written. When MainDeployer.parseManifestLibraries looks for any manifest classpath entries, there is no manifest file. The reason the MANIFEST.MF file isn't written is because o.j.util.file.JarUtils.unpackJar() only iterates through the ZipFileEntrys in the jar and writes those. Accessing the manifest requires calling JarInputStream.getManifest() and writing the result. Setting the new UnpackWars attribute to false doesn't seem to be a workaround, as when I tried this the web-console web-app blew up on deploy. I'd be happy to submit a patch for this, but would appreciate some direction from the powers that be on what you'd prefer: 1) Patch AbstractWebContainer so it writes the manifest (which would need to be a fairly ugly hack). 2) Patch JarUtils so it writes the manifest. This would seem cleaner, but has more possibility of impacting other code. Anyone know of any reason why it's not writing the manifest? Scanning a (month old) version of jboss-head, I found this method is invoked in the following places: o.j.persistence.jbossjdo.enhancer.JDOEnhancer.createTempDir () o.j.varia.deployment.FoeDeployer.inflateJar() o.j.web.AbstractWebContainer (as discussed above) o.j.web.catalina.EmbeddedCatalinaServiceSX.performDeploy() Best, Brian ---------------------------------------------------------------------- Comment By: Brian Stansberry (bstansberry) Date: 2003-08-07 09:18 Message: Logged In: YES user_id=695688 To get the zip to upload I had to remove a jar with the javax.ejb and servlet classes in it. So, if you want to rebuild the test you'll have to add those to the build classpath. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=784584&group_id=22866 ------------------------------------------------------- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
