This is definitely a bug. The J2EE 1.4 specification section J2EE.8.1
states:
"A JAR format file (such as a .jar file, .war file, or .rar
file) can reference a .jar file by naming the referenced .jar file in
a Class-Path header in the referencing JAR file’s Manifest file. The
referenced .jar file is named using a URL relative to the URL of the
referencing JAR file. The Manifest file is named META-INF/
MANIFEST.MF in the JAR file. The Class-Path entry in the Manifest
file is of the form"
Class-Path:list-of-jar-files-separated-by-spaces
"The J2EE deployment tools must process all such referenced
files when processing a J2EE module. Any deployment descriptors in
referenced .jar files are ignored when processing the
referencing .jar file. The deployment tool must install the .jar
files in a way that preserves the relative references between the
files. Typically this is done by installing the .jar files into a
directory hierarchy that matches the original application directory
hierarchy. All referenced .jar files must appear in the logical
class path of the referencing JAR files at runtime."
"Only JAR format files containing class files or resources to be
loaded directly by a standard ClassLoader should be the target of a
Class-Path reference; such files are always named with a .jar
extension. Top level JAR files that are processed by a deployment
tool should not contain Class-Path entries; such entries would, by
definition, reference other files external to the deployment unit. A
deployment tool is not required to process such external references."
I am surprised this was not caught by the TCK. This I'm going to
mark this issues as a "Blocker" since our server is non-compliant
until we fix this bug.
-dain
On Aug 14, 2005, at 11:20 AM, Jeff Genender wrote:
From your explanation, it appears you are just deploying a war. If
this is the case, why are you writing a "Class-Path" in the
MANIFEST.MF? If you store the jar The WEB-INF/lib, the server
should pick it up. The "Class-Path:" in the MANIFEST.MF is really
only when you are using an EAR. Your Class-Path is telling the
server to look for it in $GERONIMO_HOME/config-store/17/lib1.jar
and $GERONIMO_HOME/config-store/17/lib/lib2.jar. I would gather to
say this is probably a configuration issue. Place your jars in WEB-
INF/lib and remove the "Class-Path:" from your MANIFEST.MF.
Bernd Fondermann (JIRA) wrote:
Jasper TldLocationsCache initialization fails
----------------------------------------------
Key: GERONIMO-878
URL: http://issues.apache.org/jira/browse/GERONIMO-878
Project: Geronimo
Type: Bug
Components: deployment Versions: 1.0-M4 Reporter:
Bernd Fondermann
When requesting a JSP page of a geronimo-deployed WAR, I get the
following exception:
org.apache.jasper.JasperException: Unable to initialize
TldLocationsCache: $GERONIMO_HOME/config-store/17/lib1.jar
The webapp contains a META-INF/MANIFEST.MF file with a line like
that:
Class-Path: lib1.jar lib/lib2.jar
I debugged into Jasper2 and found the following:
* The code throwing the exception is in TldLocationsCache.scanJars
(), called from init()
* This method is triggered at JSP compilation time, but only for
pages containing <%@ taglib ... %> directives
* At first, the JettyClassLoader is doing its stuff
* Second, its parent, o.a.g.kernel.config.ConfigurationClassLoader
takes over
* TldLocationsCache iterates the 2 libs from the Manifest file as
returned by ConfigurationClassLoader.getURLs()
* The URLs as returned by the CL are
$GERONIMO_HOME/config-store/17/lib1.jar
$GERONIMO_HOME/config-store/17/lib/lib2.jar
* But, the files are in fact stored under
$GERONIMO_HOME/config-store/17/war/WEB-INF/lib1.jar
$GERONIMO_HOME/config-store/17/war/WEB-INF/lib/lib2.jar
* This causes a FileNotFoundException which is wrapped into the
JasperException
* If the config-store is manipulated (while running the server) to
contain these two files at the requested location, everything
works fine from then on
* Of course, the downside of this manipulation is, that deployment
fails at next server startup
