[ 
http://issues.apache.org/jira/browse/PLUTO-238?page=comments#action_12426818 ] 
            
Elliot Metsger commented on PLUTO-238:
--------------------------------------

Thanks Eric this helps.  I was partly confused because the stacktrace line 
numbers didn't match up to Pluto 1.0.1 release code. 

Anyway, it does look like the source of the problem is in 
org.apache.pluto.core.CoreUtils.getInternalResponse.  When the PortletResponse 
is unwrapped, it is casted as a PortletResponseWrapper.  I'm guessing (I 
haven't attempted to duplicate the behavior) that is where the 
ClassCastException comes from.

Here's a code snippit from CoreUtils.getInternalResponse(PortletResponse 
response):
...
        while (!(response instanceof InternalPortletResponse))
        {
            response = ((PortletResponseWrapper)response).getPortletResponse();
            if (response == null)
            {
                throw new IllegalStateException("The internal portlet response 
cannot be found.");                
            }
        }
...

After spending some time with this tonight here is my take.  JSR-168 doesn't 
provide a mechanism for wrapping PortletResponse, PortletResponseWrapper is in 
org.apache.pluto and no wrapper interfaces are defined in javax.portlet.* (By 
contrast HttpServletResponseWrapper and ServletResponse wrapper are a part of 
their respective specifications and appear in javax.servlet.*).  So in order to 
wrap a PortletResponse you'd need to depend on the implementation (By the way, 
this seems to be addressed in JSR-286 by the javax.portlet.filter.* interfaces).

Would modifying CachingHttpServletResponse to extend Pluto's 
PortletResponseWrapper be any more palateable to you (based on my reading of 
the code this would eliminate the ClassCastException, and shift the dependency 
from CacheManagingDispatcherPortlet to CachingHttpServletResponse)?

This is stuff you probably already know.  I'm putting it in here to make sure 
I'm thinking along the same lines as you.  I'll spend some more time this week 
figuring out the implementation in Pluto and think on your suggestions w.r.t. 
ThreadLocal or request attribute.

Regards -Elliot



> Wrapping RenderResponse causes ClassCastException
> -------------------------------------------------
>
>                 Key: PLUTO-238
>                 URL: http://issues.apache.org/jira/browse/PLUTO-238
>             Project: Pluto
>          Issue Type: Bug
>          Components: portlet container
>    Affects Versions: 1.0.1
>            Reporter: Eric Dalquist
>         Assigned To: Elliot Metsger
>             Fix For: 1.0.2
>
>         Attachments: CacheManagingDispatcherPortlet.java, 
> CachingHttpServletResponse.java
>
>
> I have a portlet that is attempting to wrap the RenderResponse to capture 
> data written to the PrintWriter or OutputStream to do some more advanced 
> caching. It appears that pluto depends on the implementation of the 
> RenderResponse that is passed into the PortletRequestDispatcher. I don't 
> think this is required by the portlet specification as the portlet 
> request/response objects are defined by interfaces implying the 
> implementation should not matter. The stack trace I get is:
> java.lang.ClassCastException: 
> edu.wisc.my.portlet.caching.support.CachingRenderResponse
>       at 
> org.apache.pluto.core.CoreUtils.getInternalResponse(CoreUtils.java:46)
>       at 
> org.apache.pluto.core.impl.PortletRequestDispatcherImpl.include(PortletRequestDispatcherImpl.java:45)
>       at 
> org.springframework.web.portlet.DispatcherPortlet.render(DispatcherPortlet.java:948)
>       at 
> edu.wisc.my.portlet.caching.CacheManagingDispatcherPortlet.render(CacheManagingDispatcherPortlet.java:209)
>       at 
> org.springframework.web.portlet.DispatcherPortlet.doRenderService(DispatcherPortlet.java:726)
>       at 
> edu.wisc.my.portlet.caching.CacheManagingDispatcherPortlet.doRenderService(CacheManagingDispatcherPortlet.java:179)
>       at 
> org.springframework.web.portlet.FrameworkPortlet.processRequest(FrameworkPortlet.java:420)
>       at 
> org.springframework.web.portlet.FrameworkPortlet.doDispatch(FrameworkPortlet.java:391)
>       at javax.portlet.GenericPortlet.render(GenericPortlet.java:178)
>       at 
> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:205)
>       at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:145)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
>       at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:140)
>       at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>       at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>       at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
>       at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
>       at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
>       at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
>       at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73)
>       at 
> org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:105)
>       at 
> org.jasig.portal.channels.portlet.CPortletAdapter.getMarkup(CPortletAdapter.java:690)
>       at 
> org.jasig.portal.channels.portlet.CPortletAdapter.renderCharacters(CPortletAdapter.java:593)
>       at 
> org.jasig.portal.MultithreadedCharacterChannelAdapter.renderCharacters(MultithreadedCharacterChannelAdapter.java:41)
>       at 
> org.jasig.portal.ChannelRenderer$Worker.execute(ChannelRenderer.java:603)
>       at org.jasig.portal.utils.threading.BaseTask.run(BaseTask.java:27)
>       at 
> edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:431)
>       at 
> edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:166)
>       at 
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:643)
>       at 
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:668)
>       at java.lang.Thread.run(Thread.java:595)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to