Ah, I see; Jeff is right. In the standalone scenario we can choose
to not process the entry ("A deployment tool is not required to
process such external references."). If we choose to ignore the
Class-Path entry, we should print a warning during deployment.
When the application is nested in an ear we must respect this entry.
Does anyone know if we do that?
-dain
On Aug 14, 2005, at 1:58 PM, Jeff Genender wrote:
Dain,
I dont agree this is a bug and believe this JIRA case is invalid.
This is not supposed to be appropriate for a WAR file - and
Geronimo operates exactly as its supposed to. The "Class-Path"
MANIFEST.MF attribute is invalid in a standalone war. See the
following link from Sun:
http://java.sun.com/j2ee/verified/packaging.html
This is clarified in this statement:
"Scenario 1: The application is a stand-alone WAR file that uses
one or more library files.
The application consists of a WAR file that is not packaged in an
EAR file. In J2EE 1.4, a stand-alone module such as a WAR file is a
valid J2EE application, and no EAR file wrapper is required.
In this case, you can use the WEB-INF/lib mechanism. Include the
JAR files (struts.jar, for example) in the WEB-INF/lib directory of
the WAR file; no other steps are required. The library JAR files
are packaged as part of the WAR file.
The bundled optional packages mechanism would not work, because the
WAR file in this case is a top-level application file (a stand-
alone WAR or EAR file) and top-level application files must not
have a Class-Path attribute. The attribute implies a file external
to the top-level JAR file, not one that is bundled inside it.
The installed optional packages mechanism would work. For example,
a library JAR file such as struts.jar could be placed in the
extensions directory (lib/ext). The application would need to
include a manifest file that uses the Extension-List attribute to
indicate that it needs one or more optional packages.
"
Dain Sundstrom wrote:
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
