[
https://issues.apache.org/jira/browse/PLUTO-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma reopened PLUTO-598:
-----------------------------
It turns out that while this change was needed to handle special cases on
Websphere (e.g. like a forwarded portlet request invoking a servlet include
request), this actually broke the same special cases on Tomcat :(
Tomcat has a very peculiar handling of internal dispatcher state where it
"injects" this current state *within* a request wrapper
(org.apache.catalina.core.ApplicationHttpRequest).
This means that these (there are actually two specific internal attributes
used) attributes can *only* be retrieved reliably directly from the *current*
request its parent (Tomcat "injects" the requestwrapper within the current
request).
Delegating the getAttribute call first to the PortletRequest (which by default
delegates to the container SPI PortletRequestContext implementation) thus is
not going to work out.
And especially *not* when this PortletRequestContext itself delegates again to
its wrapped servlet request ... as that one doesn't have the Tomcat injected
ApplicationHttpRequest!
Truly very complicated and tricky stuff.
Bottom line: such internal "injected" attributes simply cannot be "managed" by
the portlet container and *must* be retrieved from the current
HttpServletPortletRequestWrapper its parent.
Trouble is: this is servlet container specific, and at least Tomcat specific.
So, the previous solution which always first checked the current
HttpServletPortletRequestWrapper broke on Websphere, the new solution always on
Tomcat.
The only solution I can think of is providing special handling for these
(Tomcat and potentially other servlet containers) internal attributes.
I'm reopening this issue for both 2.0.3 and 2.1.0 versions to add handling for
these servlet container managed attributes (meaning: *not* manageable by the
portlet container).
By default I'll add handling for these Tomcat/Catalina internal attribute
names: "org.apache.catalina.core.DISPATCHER_TYPE" and
"org.apache.catalina.core.DISPATCHER_REQUEST_PATH".
As these are very Tomcat specific, these default
"servletContainerManagedAttributes" (stored in a HashSet) will not interfere
with other servlet containers.
If other servlet containers turn out needing similar/likewise special attribute
handling "protection", a static initializer method can be called (e.g. like
using Spring injection) to (re)set this attributes set.
Note: with PLUTO-600 Eric Dalquist slightly simplified the previous handling
for Pluto 2.1.0, fully delegating the getAttribute call to the
PortletRequest.getAttribute method.
As should be clear from the above however that won't work either (or at all),
so I'll have to revert that too and replace it with the described new solution
as well.
I'll add a comment therefore on PLUTO-600 indicating its solution is replaced
by this one.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
