The core of the issue here is that when you try to wrap a portlet request or response in a portlet filter like this, it does not work:
WrappedRenderResponse wrp = new WrappedRenderResponse(renderResponse);
System.out.println("SampleFilter.doFilter() : start");
The root problem is that PortletServletRequest / PortletServletResponse is not delegating its behavior to the underlying portlet request / response. Instead, it is delegating directly to the servlet counterparts. This causes problems, for example, if you want to capture and modify the portlet response in a portlet filter.
The fix here is to delegate as much responsibility in the PortletServletRequest / PortletServletResponse to the corresponding portlet request / response.
This is a "higher" risk fix but it is the correct one. We'll need to run this against the TCK and flush out any other problems from this change as they arise.
I've also attached a sample portlet that can be used to test.
For reference, the intended behavior is specified in the Portlet 2.0 Spec PLT 20.X:
JSR 286 PLT 20.1
Among the types of functionality available to the developer needing to use filters are the following:
The modification of response data by providing customized versions of the response object.
The method may wrap the response object passed in to its doFilter method with a customized implementation of one of the response wrappers ActionResponse, EventResponse, RenderResponse, ResourceResponse) to modify response data.
After invocation of the next filter in the chain, the filter may examine the response data
When a filter invokes the doFilter method on the portlet container's filter chain implementation, the container must ensure that the request and response object that it passes to the next component in the filter chain, or to the target portlet if the filter was the last in the chain, is the same object that was passed into the doFilter method by the calling filter or one of the above mentioned wrappers."