tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 56016] New: DigesterFactory.idFor(...) assumes that javax.servlet.jsp.resources.** are available from the same class loader that defines javax.servlet.ServletContext
Date Wed, 15 Jan 2014 23:51:30 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=56016

            Bug ID: 56016
           Summary: DigesterFactory.idFor(...) assumes that
                    javax.servlet.jsp.resources.** are available from the
                    same class loader that defines
                    javax.servlet.ServletContext
           Product: Tomcat 7
           Version: 7.0.50
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina
          Assignee: dev@tomcat.apache.org
          Reporter: dmitri.bourlatchkov@gmail.com

Created attachment 31214
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=31214&action=edit
Patch for DigesterFactory.ifFor(...) method to relax assumptions related to
class loading

The idFor(String url) method in
org.apache.tomcat.util.descriptor.DigesterFactory appears to try loading
resources from the javax.servlet.jsp.resources package using the defining class
loader of javax.servlet.ServletContext.

This is perfectly fine for standalone Tomcat, of course. However, in our
application we run embedded Tomcat in an isolated class loader, which includes
all of Tomcat's jar files _except_ servlet-api.jar. servlet-api.jar is part of
the class loader that is a  parent of the class loader for the embedded Tomcat.

Tomcat 7.0.47 worked well in this setup. However in 7.0.50 we hit exceptions
like the following:

java.lang.ExceptionInInitializerError
    at
org.apache.catalina.startup.TldConfig.createTldDigester(TldConfig.java:94)
    at org.apache.catalina.startup.TldConfig.init(TldConfig.java:576)
    at org.apache.catalina.startup.TldConfig.lifecycleEvent(TldConfig.java:559)
    at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
    at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
    at
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:402)
    at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:110)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139)
    at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
    at
org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133)
    at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156)
    at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875)
    at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:634)
    [...]
Caused by: java.lang.NullPointerException
    at
org.apache.tomcat.util.descriptor.DigesterFactory.idFor(DigesterFactory.java:107)
    at
org.apache.tomcat.util.descriptor.DigesterFactory.<clinit>(DigesterFactory.java:59)
    ... 25 more 

The reason why the resource is not found is apparently that the class loader of
ServletContext does not 'see' resources from jsp-api.jar.

We can work around that by placing jsp-api.jar into the same class loader that
has servlet-api.jar, however this workaround is not ideal from our design
perspective.

>From the source of the idFor(...) method one could guess that the fallback
attempt to find the requested resource in the javax.servlet.jsp.resources
package is meant to look in jsp-api.jar. For that reason, would it be
appropriate to perform the fallback lookup in the defining class loader of
javax.servlet.jsp.JspContext? A patch file for the proposed fix is attached. If
it is accepted please credit Juan Carlos Estibariz with it.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message