You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Bernd Fondermann (JIRA)" <de...@geronimo.apache.org> on 2005/08/14 20:03:54 UTC
[jira] Created: (GERONIMO-878) Jasper TldLocationsCache initialization fails
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
--
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
Re: [jira] Created: (GERONIMO-878) Jasper TldLocationsCache initialization fails
Posted by Dain Sundstrom <da...@iq80.com>.
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
>>>>
>>>
>>>
>
Re: [jira] Created: (GERONIMO-878) Jasper TldLocationsCache initialization
fails
Posted by Jeff Genender <jg...@savoirtech.com>.
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
>>
>>
>
Re: [jira] Created: (GERONIMO-878) Jasper TldLocationsCache initialization fails
Posted by Dain Sundstrom <da...@iq80.com>.
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
>
Re: [jira] Created: (GERONIMO-878) Jasper TldLocationsCache initialization
fails
Posted by Jeff Genender <jg...@savoirtech.com>.
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
>
>
>
[jira] Closed: (GERONIMO-878) Web deployer ignores manifest class path entries
Posted by "Jeff Genender (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-878?page=all ]
Jeff Genender closed GERONIMO-878:
----------------------------------
Resolution: Invalid
This is not a bug...its covered in the J2EE 1.4 spec, page 122:
"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 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
--
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
[jira] Commented: (GERONIMO-878) Jasper TldLocationsCache initialization fails
Posted by "Bernd Fondermann (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-878?page=comments#action_12318755 ]
Bernd Fondermann commented on GERONIMO-878:
-------------------------------------------
After removing the Manifest, everything works fine.
Geronimo just thinks, that the Manifest-Class-Path references are not relative to WEB-INF/ (that's what I thought), but to the web app root.
Although Geronimo seems to be right, other containers apparently handle this differently, so for me this issue never popped up before.
Case resolved... Lesson learned.
> 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
--
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
[jira] Updated: (GERONIMO-878) Web deployer ignores manifest class path entries
Posted by "Dain Sundstrom (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-878?page=all ]
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"
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."
> 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 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
--
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