[
https://issues.apache.org/jira/browse/PLUTO-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma resolved PLUTO-529.
-----------------------------
Resolution: Fixed
All fixed and implemented with the recent big bang refactoring and final
commits r753592 and r753593
> PortletRequest/PortletResponse implementations extending
> HttpServletRequest/Response wrappers causes "indentity" problems when
> accessed from servlets
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: PLUTO-529
> URL: https://issues.apache.org/jira/browse/PLUTO-529
> Project: Pluto
> Issue Type: Bug
> Components: portlet container
> Affects Versions: 2.0.0
> Reporter: Ate Douma
> Assignee: Ate Douma
> Priority: Critical
> Fix For: 2.0.0
>
>
> Below copied (in part) from email discussion on the Pluto dev list, see also:
> http://www.nabble.com/More-required-Pluto-2.0-SPI-and-implementation-refactoring-issues-td21973310.html
> *** InternalPortletRequest/Response implementations (and subclasses thereof)
> extending HttpServletRequest/ResponseWrapper
> This solution (dating back from Pluto 1.0 implementation) has a very tricky
> but serious flaw.
> By using a single instance HttpServletRequestWrapper instance for both the
> PortletRequest and dispatched ServletRequest,
> a dispatched servlet retrieving the current PortletRequest (or Response)
> using HttpServletRequest.getAttribute("javax.portlet.request") as
> specified by the Portlet specification (PLT.19.3.2), will actually return the
> *current* HttpServletRequestWrapper itself again.
> So far, nothing wrong yet.
> But, as the InternalPortletRequestImpl (which is the real implementation
> class) also maintains internal instance state concerning its dispatched state
> and based upon that decides how overlapping methods need to behave, the
> PortletRequest object
> retrieved like this from within a servlet environment actually behaves as a
> dispatched ServletRequest.
> This is *not* compliant with the Portlet specification, even if the current
> JSR-286 TCK doesn't (properly) test against this.
> The only solution to solve this is *not* using a piggy back solution for the
> dispatched ServletRequest/Response objects, but use independent
> instances for the PortletRequest/Response and wrap these within the
> dispatched ServletRequest/Response objects.
> This is a rather big change, but really required.
> On the bright side, doing so will result in a much more readable/maintainable
> solution as the current implementation has to maintain some tricky state
> flags to keep track of its "identity". Getting rid of all that and moving the
> dispatched servlet specific handling in separate
> classes will make this much easier and transparent to deal with.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
