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



Reply via email to