Bug 39844 - non-HTTP forward will alway result NullPointerException
Summary: non-HTTP forward will alway result NullPointerException
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 5.5.17
Hardware: All other
: P4 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-06-20 15:41 UTC by Henry Wong
Modified: 2009-12-20 09:53 UTC (History)
0 users


Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Henry Wong 2006-06-20 15:41:19 UTC 
When forwarding with customed ServletRequest/ServletResponse (which implement
javax.servlet.ServletRequest and javax.servlet.ServletResponse) will alway
result an NullPointerException, stack trace as follow:

java.lang.NullPointerException
	at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:453)
	at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:341)
	at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
	at xxx.TestServlet.doGet(TestServlet.java:40)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
	at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
	at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
	at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
	at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
	at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
	at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
	at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
	at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
	at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
	at java.lang.Thread.run(Thread.java:595)

I suspect these is logical bug:

        // Identify the HTTP-specific request and response objects (if any)
        HttpServletRequest hrequest = null;
        if (request instanceof HttpServletRequest)
            hrequest = (HttpServletRequest) request;
        HttpServletResponse hresponse = null;
        if (response instanceof HttpServletResponse)
            hresponse = (HttpServletResponse) response;

        // Handle a non-HTTP forward by passing the existing request/response
        if ((hrequest == null) || (hresponse == null)) {

            if ( log.isDebugEnabled() )
                log.debug(" Non-HTTP Forward");
            
            processRequest(hrequest,hresponse);

        }

If "hrequest" or "hresponse" is null, why we are giving up "request" and
"response" here?
Comment 1 Yoav Shapira 2006-06-20 15:45:18 UTC 
Good question -- ask on the dev list maybe.

But also another question: why are you extending HttpServlet and using its
method-sensing ability (GET in this case) if your servlet is not HTTP?
Comment 2 Henry Wong 2006-06-20 16:15:13 UTC 
(In reply to comment #1)
> Good question -- ask on the dev list maybe.
> 
> But also another question: why are you extending HttpServlet and using its
> method-sensing ability (GET in this case) if your servlet is not HTTP?

This is just a test Servlet, the source of the request can be any other
application generated request to the container. If catalina is supposed NOT to
handle non-HTTP request, why the code here show me that it is trying to handle
it and handle it in a buggy way?

Maybe I am wrong, I find a "hard cast" in invoke too:

    private void invoke(ServletRequest request, ServletResponse response)
            throws IOException, ServletException {

        // Checking to see if the context classloader is the current context
        // classloader. If it's not, we're saving it, and setting the context
        // classloader to the Context classloader
        ClassLoader oldCCL = Thread.currentThread().getContextClassLoader();
        ClassLoader contextClassLoader = context.getLoader().getClassLoader();

        if (oldCCL != contextClassLoader) {
            Thread.currentThread().setContextClassLoader(contextClassLoader);
        } else {
            oldCCL = null;
        }

        // Initialize local variables we may need
        HttpServletRequest hrequest = (HttpServletRequest) request;
        HttpServletResponse hresponse = (HttpServletResponse) response
...
Comment 3 Mark Thomas 2009-07-12 03:45:35 UTC 
This was fixed for 6.0.x (bug 43668) in r588477.

I have proposed a port of the same fix for 5.5.x
Comment 4 Mark Thomas 2009-12-20 09:53:00 UTC 
Thsi has been fixed in 5.5.s and will be included in 5.5.29 onwards.