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.
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.