Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Message-ID: <826930482.1124047494120.JavaMail.jira@ajax.apache.org>
Date: Sun, 14 Aug 2005 21:24:54 +0200 (CEST)
From: "Dain Sundstrom (JIRA)" <dev@geronimo.apache.org>
To: dev@geronimo.apache.org
Subject: [jira] Updated: (GERONIMO-878) Web deployer ignores manifest class
 path entries
In-Reply-To: <1439222097.1124042634272.JavaMail.jira@ajax.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

     [ http://issues.apache.org/jira/browse/GERONIMO-878?page=3Dall ]

Dain Sundstrom updated GERONIMO-878:
------------------------------------

      Component: web
        Summary: Web deployer ignores manifest class path entries  (was: Ja=
sper 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 r=
eference a .jar file by naming the referenced .jar file in a Class-Path hea=
der in the referencing JAR file=E2=80=99s Manifest file.  The referenced .j=
ar file is named using a URL relative to the URL of the referencing JAR fil=
e.  The Manifest file is named META-INF/MANIFEST.MF in the JAR file.  The C=
lass-Path entry in the Manifest file is of the form"

    Class-Path:list-of-jar-files-separated-by-spaces=20

    "The J2EE deployment tools must process all such referenced files when =
processing a J2EE module.  Any deployment descriptors in referenced .jar fi=
les are ignored when processing the referencing .jar file.  The deployment =
tool must install the .jar files in a way that preserves the relative refer=
ences between the files.  Typically this is done by installing the .jar fil=
es into a directory hierarchy that matches the original application directo=
ry hierarchy.  All referenced .jar files must appear in the logical class p=
ath of the referencing JAR files at runtime."=20
    "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 re=
ference; 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: http://issues.apache.org/jira/browse/GERONIMO-878
>      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 followin=
g 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(), cal=
led from init()
> * This method is triggered at JSP compilation time, but only for pages co=
ntaining <%@ 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 returne=
d 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 JasperExc=
eption
> * If the config-store is manipulated (while running the server) to contai=
n these two files at the requested location, everything works fine from the=
n on
> * Of course, the downside of this manipulation is, that deployment fails =
at next server startup

--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira