You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2003/02/05 23:56:20 UTC

DO NOT REPLY [Bug 16821] New: - Unable to compile JSP pages with jstl tag libraries.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16821>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16821

Unable to compile JSP pages with jstl tag libraries.

           Summary: Unable to compile JSP pages with jstl tag libraries.
           Product: Tomcat 4
           Version: 4.1.12
          Platform: All
        OS/Version: Other
            Status: NEW
          Severity: Critical
          Priority: Other
         Component: Jasper 2
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: kelly.chen@tumbleweed.com


I can reproduce this easily. For any JSP pages that uses the standard tag lib
with the following line.
<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
I will run into errors when using JspC to compile from command line. I use the
following command line to compile Jsp pages:
java org.apache.jasper.JspC -d output_dir -p my.package -uriroot jsp 

I also need to put standard.jar under jsp/WEB-INF/lib for JspC to find it. An
error will occur. 

I also did a bit digging to see why the same Jasper library compiles Jsp fine
for a web-app, but not from command line. The following is what I found.The
culprit is the following line of code in the constructor of TagLibraryInfoImpl.java

               if(ctxt.getClassLoader() != null &&
                 
java.net.URLClassLoader.class.equals(ctxt.getClassLoader().getClass())
                  && path.startsWith("/"))
               {
                   path = path.substring(1,path.length()) ;
               }
               url = ctxt.getResource(path);

When running from the web-app. The ctxt object is JspEngineContext (I am looking
at a Jetty class). Its class loader is different from java.net.URLClassLoader,
so it will not trigger the action to strip out the "/".

When running JspC to compile the JSP pages, the ctxt object is
JspCompilationContext. Its class loader is URLClassLoader, so it will trigger
the stripping action.

However both context objects do not use class loader to getResource. Instead
both use javax.servlet.ServletContext.getResource, which requires the string to
be started with "/" according to Servlet spec. So the check for the class loader
here makes no sense here. It is clearly a bug that the code strips out the
starting "/" prior to calling ctxt.getResource. 

I would suggest to take out the above code that checks for class loader and
remove the starting "/".

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