Re: [gatein-dev] Request dispatching clarification

Hi, I would like to clarify things about request dispatching in GateIn and in servlet container more generally. Because there are many expectations that are not correct and people are not usually aware of this, so I think there is a need for a clarification on several points. 1/ When a request dispatch is performed from a servlet to another servlet in the same web application or in a different web application (cross context dispatch), the request and response provided can be custom request and response BUT they must subclass ServletRequestWrapper and ServletResponseWrapper. There are at least two good reasons for this: - The best one: the spec simply **mandates it** : http://download.oracle.com/javaee/5/api/javax/servlet/RequestDispatcher.h... . "The request and response parameters must be either the same objects as were passed to the calling servlet's service method or be subclasses of the ServletRequestWrapper or ServletResponseWrapper classes that wrap them." - If a custom subclasses are made and implements the interface of HttpServletRequest and HttpServletResponse, it will create code that will only run with the servlet API for which is was compiled. If it is compiled with Servlet 2.5 API, then it will lead to classloading exception in a Servlet 3.0 container. Conversely if it compiled with Servlet 3.0 API, then it will not work anymore in Servlet 2.5 container because it will want to load non existing classes (like for instance the new class javax.servlet.http.Part in Servlet 3.0) 2/ When a request dispatch occurs from one web application to another web application, the http request/response used for dispatching must not be used during the dispatched invocation. We have a chain like: Container ---> Filter (/a) ---> Container ---> Servlet (/a) ---> Container [RD to /b] ---> Filter (/b) ---> Container ---> Servlet (/b) The Container is nearly in between all the various layers (filters and servlets) and is performing important work. When dispatched in /b, using the request/response of /a is not a correct thing to do. 3/ I know that GateIn does not provide a good solution for case 2 and we have had bugs recently with that, mainly because code wants to store attributes in a scope that is common to all web applications (i.e the portal session). So for now we are fixing things to make them work, but in the next version of GateIn, we will come up with a correct solution for that. I think also (that's my personal point of view), that the PortletRequest and PortletResponse are not used when they should be, meaning that there is no solution for sharing state between portlet that are not in the same web application. So we will try to come with the best solution. cheers Julien