You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by "Ate Douma (JIRA)" <ji...@apache.org> on 2009/02/19 16:04:02 UTC
[jira] Created: (PLUTO-529) PortletRequest/PortletResponse
implementations extending HttpServletRequest/Response wrappers causes
"indentity" problems when accessed from servlets
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.
(side note: I actually wrote a test case for this and this spec requirement is broken in most other open-source portlet containers as well!)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (PLUTO-529) PortletRequest/PortletResponse
implementations extending HttpServletRequest/Response wrappers causes
"indentity" problems when accessed from servlets
Posted by "Ate Douma (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PLUTO-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ate Douma updated PLUTO-529:
----------------------------
Description:
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.
was:
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.
(side note: I actually wrote a test case for this and this spec requirement is broken in most other open-source portlet containers as well!)
> 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.
[jira] Resolved: (PLUTO-529) PortletRequest/PortletResponse
implementations extending HttpServletRequest/Response wrappers causes
"indentity" problems when accessed from servlets
Posted by "Ate Douma (JIRA)" <ji...@apache.org>.
[ 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.