svn commit: r754514 - /portals/pluto/trunk/pluto-container/src/main/java/org/apache/pluto/container/impl/HttpServletPortletRequestWrapper.java

[at...@apache.org]

Author: ate
Date: Sat Mar 14 20:21:51 2009
New Revision: 754514

URL: http://svn.apache.org/viewvc?rev=754514&view=rev
Log:
Fixing servlet filter support (among others) for dispatched servlets by allowing (first) attribute access to the *current* servletrequest parent.
(how "nice" the TCK doesn't check these kind of standard servlet (filters) interactions...)
This fix gets Wicket portlet support working again.

Modified:
    portals/pluto/trunk/pluto-container/src/main/java/org/apache/pluto/container/impl/HttpServletPortletRequestWrapper.java

Modified: portals/pluto/trunk/pluto-container/src/main/java/org/apache/pluto/container/impl/HttpServletPortletRequestWrapper.java
URL: http://svn.apache.org/viewvc/portals/pluto/trunk/pluto-container/src/main/java/org/apache/pluto/container/impl/HttpServletPortletRequestWrapper.java?rev=754514&r1=754513&r2=754514&view=diff
==============================================================================
--- portals/pluto/trunk/pluto-container/src/main/java/org/apache/pluto/container/impl/HttpServletPortletRequestWrapper.java (original)
+++ portals/pluto/trunk/pluto-container/src/main/java/org/apache/pluto/container/impl/HttpServletPortletRequestWrapper.java Sat Mar 14 20:21:51 2009
@@ -501,7 +501,24 @@
             }
             return null;
         }
-        return portletRequest.getAttribute(name);
+        
+        /*
+         * First try to access the attribute from the *parent* request.
+         * Webcontainers typically "inject" a custom servletrequest in between the
+         * dispatched request (this) and its original "parent", to ensure proper
+         * management of requestdispatcher state.
+         * Webcontainer specific attributes therefore *must* be accessed from the
+         * *current* parent request to ensure proper behavior
+         * Without doing this, for instance Tomcat fails to properly match
+         * servlet filters properly, if at all...
+         * This should not really interfere with normal PortletRequest attribute
+         * management as the PortletRequestContext implementation is assumed to
+         * encode newly set attributes anyway or store them otherwise, hence going
+         * through the current parent request *first* should not yield those
+         * attributes.
+         */
+        Object value = getRequest().getAttribute(name);
+        return value != null ? value : portletRequest.getAttribute(name);
     }
 
     @Override