On 23/11/10 02:44, Eric Dalquist (JIRA) wrote:
[
https://issues.apache.org/jira/browse/PLUTO-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934693#action_12934693
]
Eric Dalquist commented on PLUTO-598:
-------------------------------------
So my primary concern here is the when the portal wants to have complete
control the request attributes a portlet sees when getAttribute() is called on
the PortletRequest or the ServletRequest based on the PortletRequest. The
primary issue I was trying to address with PLUTO-600 was having the fallback
logic in the HttpServletPortletRequestWrapper means that there is no reasonable
way for a portal to influence this attribute resolution logic. My request is
that if at all possible this logic should be part of the default
PortletRequestContext SPI implementation so that implementing portals can still
have full control over this attribute resolution.
Hi Eric,
AFAIK the portal still has (and had) this level of control already.
The only exception I've now added is for these specific and servlet container
managed attributes.
But this is still configurable if you really want or need to "disable" or customize this, although I think a portal shouldn't (cannot)
interfere with the servlet container on this level (request dispacher state managment).
With regard to PLUTO-600: except for these specific attributes, flow of control is always passed on to the (portal controllable)
portletRequest.getAttribute method.
The only possible problem I can see (just now occurred to me while writing this) would be when the portal explicitly wants to "hide" certain
attributes, e.g. by returning a null value.
The solution I just committed then won't work as in that case the HttpServletPortletRequestWrapper will still delegate to
getRequest().getAttribute thereafter...
Hmm, I need to think a little bit more about it, but probably just only delegating to portletRequest.getAttribute might be good enough, like
your original PLUTO-600 fix, certainly now that these special container managed attributes are taken care of upfront.
The only possible caveat of that is the portletRequest cannot "see" the current HttpServletPortletRequestWrapper its getRequest() parent, so
it might yield yet a different result!
The only proper solution for this would be adding a new getAttribute(String name, ServletRequest currentRequest) method, passing full
control over to the portal.
But that is an API/SPI change not to be taken lightly for PLUTO 2.0.x.
For PLUTO 2.1.x however it might be OK.
WDYT?
Regards,
Ate
Retrieving Portlet invoked servlet request attributes should first check
PortletRequest attributes before using fallback to the web container
----------------------------------------------------------------------------------------------------------------------------------------------
Key: PLUTO-598
URL: https://issues.apache.org/jira/browse/PLUTO-598
Project: Pluto
Issue Type: Bug
Components: portlet container
Affects Versions: 2.0.2
Reporter: Ate Douma
Assignee: Ate Douma
Fix For: 2.0.3, 2.1.0
In
o.a.pluto.container.impl.HttpServletPortletRequestWrapper.getAttribute(String)
a (non path related) attribute currently first is looked up from
getRequest().getAttribute(String) with a fallback to the
PortletRequest.getAttribute(String).
However, this is the wrong order: first the PortletRequest.getAttribute(String)
should be checked to ensure a possibly earlier set attribute which is *only*
set with PortletRequest.setAttribute(String,Object) (and possibly cached there)
is returned.
