> I had directed Eric over here from the uPortal lists. > > It appears that the JSF-Portlet library adds a response wrapper before > calling the request dispatcher. Does anyone here know if that is allowed > under JSR-168? There is no mention I can find in the spec or errata. I > do know in 286 explicit wrapper classes were added that mimic the > servlet API wrapper classes but that is all I've been able to find. > Should this be viewed as a Pluto bug or a JSF-Portlet bug? > > -Eric
I would expect the PortletRequestDispatcher.include() should accept any implementation of PortletRequest/Response, but that is probably not guaranteed by the spec. Even if this is not a Pluto bug, I wonder if a simple fix might be to use a ThreadLocal to store the internal request/response objects when o.a.p.core.PortletServlet passes the request off to the portlet, rather than using wrapper classes. Actually, as I look at the code, I wonder if PortletRequestDispatcherImpl.include should wrap the PortletRequest/Response objects in adapters that implement HttpServletRequest/Response rather than unwrap them to pull out the internal implementation. That way, the client's wrapper classes could still function as expected. I could put together a patch for this if you think it is a good idea. -- Ben P.S. - I'm replying to pluto-user, but I wonder if this is more appropriate for pluto-dev?
