Re: Problem with Pluto Portlets and the Sun JSF Portlets

[Michael Freedman]

Request and Response wrapping is not supported in the Portlet 1.0 (JSR 168) standard hence the use of a request wrapper by the Sun JSF bridge ( it is the Sun bridge, right?) is implementation dependent and can only be assumed to work in a Sun portlet container.  Instead, try the JSR 301 Bridge whose (early) Reference Implementation is on Apache (http://myfaces.apache.org/portlet-bridge/index.html).  I would suggest getting the sources and building yourself as the last release was posted coincident with the last early draft  earlier this year and things have progressed a bit since then.  (Though that binary release is also stable and fully functional for most uses).  Note: this impl is intended to be portlet container independent.  It doesn't rely on wrapping. When you look at this Apache project you will notice there are two code lines.  The JSR is producing a spec and impl for both portlet 1.0 and portlet 2.0 with JSF 1.2.  Portlet 2.0 (JSR 286) does define wrapping, hence its the portlet 2.0 bridge version that wanted to use wrapping and hit the bug referenced by Craig.      -Mike- [EMAIL PROTECTED] wrote: PLUTO-478 covers this issue. It was reported by Mike Freedman, spec lead of JSR-301, the JSF-Portlet Bridge.   Any fix to this issue should be done on the 1.1.x and 2.0-refactoring branch and the trunk. /Craig     [EMAIL PROTECTED] wrote: ----- To: pluto-user@portals.apache.org From: [EMAIL PROTECTED] Date: 08/05/2008 07:29PM Subject: Re: Problem with Pluto Portlets and the Sun JSF Portlets > 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?