[ 
http://issues.apache.org/jira/browse/PLUTO-238?page=comments#action_12426260 ] 
            
Eric Dalquist commented on PLUTO-238:
-------------------------------------

I don't have the code I was working with when I created the issue. I do have 
the currently working code though.

The lines pertaining to pluto are 127 to 144 of CacheManagingDispatcherPortlet. 
Particularly the comment on lines 140 - 144.

The CachingRenderResponse was very close to what the attached 
CachingHttpServletResponse code does.


The concept for the code is the root portlet wraps the RenderResponse in an 
implementation that captures any data written out and stores it in a cache. The 
problem is when a call is made to render a JSP and the code execution path goes 
back into pluto it is expecting a RenderResponse implementation that it knows.

Perhaps Pluto could get the InternalRenderResponse from the request attributes 
or a ThreadLocal to avoid needing to unwrap the RenderResponse that is passed 
to it.


Let me know if you need anything else.

> 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