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?
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?
(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 ...
This was fixed for 6.0.x (bug 43668) in r588477. I have proposed a port of the same fix for 5.5.x
Thsi has been fixed in 5.5.s and will be included in 5.5.29 onwards.