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
/Craig
[EMAIL PROTECTED] wrote: -----
To: [email protected]
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?
