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