HTTP Servlet RequestDispatcher 'forward' has invalid request pathInfo
---------------------------------------------------------------------

                 Key: FELIX-2774
                 URL: https://issues.apache.org/jira/browse/FELIX-2774
             Project: Felix
          Issue Type: Bug
          Components: HTTP Service
    Affects Versions: http-2.0.4
            Reporter: David Hay


I'm trying to have one servlet forward to another servlet.  However, the 
forwarding doesn't seem to work.

I've set up the proxy servlet in my web.xml as follows (and this is the only 
servlet...no filters defined)

    <servlet>
        <servlet-name>osgi-servlet-bridge</servlet-name>
        <servlet-class>org.apache.felix.http.proxy.ProxyServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>osgi-servlet-bridge</servlet-name>
        <url-pattern>/*</url-pattern>
    </servlet-mapping>


I then have two bundles, each registers a servlet under a different path (e.g. 
bundle A registers under alias '/a' and bundle B registers under alias '/b') 
using the whiteboard pattern.  The implementation of servlet A ends up doing 
this:

RequestDispatcher rd = request.getRequestDispatcher("/b/some/path");
rd.forward(request, response);

This finds the ServletHandler for servlet B just fine, but gets hung up in the 
'handle' method. I think this is due to the implementation of the internal 
RequestWrapper class in the ServletPipeline class.  This implementation 
overrides the getRequestURI method with the passed in value.  However, 
ServletHandler.handle passed the result of HttpServletRequest.getPathInfo() to 
the 'matches' method as a final check to make sure that the servlet should be 
invoked.  Since the RequestWrapper class does not override getPathInfo, it 
returns the value from the original request....which is '/a' in my example.
 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to