On 11 Jan 2010, at 19:43, Felix Meschberger wrote: > > > On 08.01.2010 16:31, Ian Boston wrote: >> We have been trying to implement a Batch method processor (ie a servlet that >> performs multiple requests batching the responses up into a single >> request/response) in Sling. >> >> Normally with servlets this would require >> requestDispacher.forward(wrappedRequest, wrappedResponse) but this doent >> work since Sling unwrapps all request back to a internal >> SlingHttpServletRequestImpl object so although you can get hold of the >> requestDispatcher, and call the forward method, its almost pointless. > > I fear, I do not completely understand the problem. > > You can provide any SlingHttpServletRequest|Response to the forward > method and this instance will be presented to the included servlet. > > If not the provided instances are given to the included servlet, I would > consider this a major issue.... > >> >> Whats the right way of doing this sort of thing in Sling ? > > I would say that it should be possible to forward multiple times > collecting the output -- you would just have to make sure, no output and > headers are really written back by the servlets/scripts forwarded to. > Thus the wrappedResponse would have to make sure not to set responses > headers (by default in Sling included servlets *can* set response > headers unlike in the Servlet API, where this is not possible).
Wrapping the response works perfectly, Wrapping the request does not. The SlingRequestDispatcher uses the RequestData.unwrap(...) to unwrap any request back to the first SlingHttpServletRequestImpl (private to the engine bundle) effectively negating any attempt to wrap the request object. Perhaps there should be a marker interface to identify when its safe to use a request object and when it needs to be unwrapped further. Ian > > Regards > Felix > >> >> Ian >> >> BTW, we have also tried Filters registered against the SlingMainSevlet (via >> OSGI), adding another top level servlet directly to the httpservice and >> adding filters at the http service level before the SlingMainServlet. None >> appear to work for all sorts of reason, sadly perfectly valid and to spec.
