[
https://issues.apache.org/jira/browse/PLUTO-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647057#action_12647057
]
Ate Douma commented on PLUTO-478:
---------------------------------
Hi Mike,
I just did look at this "feature" and I can see this "unwrapping" is done for
two different reasons:
a) to be able to mark the request/response internal state as being
included/forwarded for which the Portlet API requires different handling
b) to be able to do the actual *servlet* dispatch using the
ServletRequestDispatcher which only can take a ServletRequest & ServletResponse
as parameters
I think it's not difficult to come up with a solution for a) by using only
temporarily "unwrapping" just to mark the internal state.
Note though, this then will leave the door open for actual wrappers to "break"
the Portlet API requirements when overriding some of the specific methods
"incorrectly".
But, the second reason b) really is a killer: how would you do the actual
servlet dispatch which requires the underlying ServletRequest/ServletResponse
without unwrapping?
Maybe wrapping the (possibly itself wrapped) PortletRequest/PortletResponse
with yet another HttpServletRequestWrapper/HttpServletResponseWrapper and
delegate all their methods back to the PortletRequest/PortletResponse?
I'm not sure that's 100% guaranteed to work on all (or at least some) web
containers which, like Tomcat, sometimes do their own "unwrapping" to get to
their own internal state...
And what should be returned for the following method then: ServletRequest
HttpServletRequestWrapper.getRequest()?
I'm willing to try to solve this one, but right now I don't see a "solid"
solution yet. But if you have any ideas what might work (without resorting to
webcontainer/vendor specific solutions) I'm all ears!
> Portlet Dispatching loses wrappers
> ----------------------------------
>
> Key: PLUTO-478
> URL: https://issues.apache.org/jira/browse/PLUTO-478
> Project: Pluto
> Issue Type: Bug
> Components: portlet container
> Affects Versions: 2.0.0
> Reporter: Michael Freedman
> Fix For: 2.0.0
>
>
> When you dispatch using a wrapped request/response object, pluto doesn't
> preserve the wrapping when it executes the dispatch. I.e. it upwraps the
> request/response and dispatches on that. This prevents portlets from
> filtering request/responses to/from dispatched/servlet entities.
> It would be nice if we added a TCK test for this case as well. The spec is
> clear that one can use a wrapped request/response to dispatch to. Though it
> doesn't specifically state that this must be preserved, it not only is the
> reasonable interpreation/expectation but is what clients will be counting on.
> Hence for the sake of interoperability, having a TCK test will catch this
> problem early.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
