geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dain Sundstrom (JIRA)" <>
Subject [jira] Updated: (GERONIMO-878) Web deployer ignores manifest class path entries
Date Sun, 14 Aug 2005 19:24:54 GMT
     [ ]

Dain Sundstrom updated GERONIMO-878:

      Component: web
        Summary: Web deployer ignores manifest class path entries  (was: Jasper TldLocationsCache
initialization fails)
    Fix Version: 1.0-M5
       Priority: Blocker  (was: Major)

This is J2EE 1.4 compliancy issue. 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"


    "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."

> Web deployer ignores manifest class path entries
> ------------------------------------------------
>          Key: GERONIMO-878
>          URL:
>      Project: Geronimo
>         Type: Bug
>   Components: deployment, web
>     Versions: 1.0-M4
>     Reporter: Bernd Fondermann
>     Priority: Blocker
>      Fix For: 1.0-M5

> 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

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message