You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by "Eric Dalquist (JIRA)" <ji...@apache.org> on 2006/05/03 17:04:46 UTC
[jira] Created: (PLUTO-238) Wrapping RenderResponse causes
ClassCastException
Wrapping RenderResponse causes ClassCastException
-------------------------------------------------
Key: PLUTO-238
URL: http://issues.apache.org/jira/browse/PLUTO-238
Project: Pluto
Type: Bug
Components: portlet container
Versions: 1.0.1
Reporter: Eric Dalquist
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
[jira] Commented: (PLUTO-238) Wrapping RenderResponse causes
ClassCastException
Posted by "Elliot Metsger (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/PLUTO-238?page=comments#action_12427780 ]
Elliot Metsger commented on PLUTO-238:
--------------------------------------
erm, s/InternalRenderResponse/InternalPortletResponse/g
> 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, PLUTO238-01.patch
>
>
> 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
[jira] Commented: (PLUTO-238) Wrapping RenderResponse causes
ClassCastException
Posted by "Elliot Metsger (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/PLUTO-238?page=comments#action_12426108 ]
Elliot Metsger commented on PLUTO-238:
--------------------------------------
Eric,
Any chance I could see the code for edu.wisc.my.portlet.caching.support.CachingRenderResponse and edu.wisc.my.portlet.caching.CacheManagingDispatcherPortlet, or get a copy from your svn?
> 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
>
>
> 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
[jira] Commented: (PLUTO-238) Wrapping RenderResponse causes
ClassCastException
Posted by "Eric Dalquist (JIRA)" <ji...@apache.org>.
[ 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
[jira] Updated: (PLUTO-238) Wrapping RenderResponse causes
ClassCastException
Posted by "Craig Doremus (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/PLUTO-238?page=all ]
Craig Doremus updated PLUTO-238:
--------------------------------
Fix Version: 1.0.2
> Wrapping RenderResponse causes ClassCastException
> -------------------------------------------------
>
> Key: PLUTO-238
> URL: http://issues.apache.org/jira/browse/PLUTO-238
> Project: Pluto
> Type: Bug
> Components: portlet container
> Versions: 1.0.1
> Reporter: Eric Dalquist
> Fix For: 1.0.2
>
> 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
[jira] Updated: (PLUTO-238) Wrapping RenderResponse causes
ClassCastException
Posted by "Elliot Metsger (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/PLUTO-238?page=all ]
Elliot Metsger updated PLUTO-238:
---------------------------------
Attachment: PLUTO238-01.patch
Eric, I'm attaching PLUTO238-01.patch which stores the InternalRenderResponse as a request attribute.
The patch modifies PortletContainerImpl to add the InternalRenderResponse as a request attribute. (TODO see if the redirect method needs any adjustment)
The patch adds two methods to CoreUtils:
getInternalRenderResponse(PortletRequest, PortletResponse)
getInternalRenderResponse(ServletRequest, PortletResponse)
The patch modifies a number of classes that are clients of CoreUtils.
Can you apply the patch and see if it works for you?
> 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, PLUTO238-01.patch
>
>
> 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
[jira] Commented: (PLUTO-238) Wrapping RenderResponse causes
ClassCastException
Posted by "Elliot Metsger (JIRA)" <ji...@apache.org>.
[ 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
[jira] Resolved: (PLUTO-238) Wrapping RenderResponse causes
ClassCastException
Posted by "David DeWolf (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/PLUTO-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David DeWolf resolved PLUTO-238.
--------------------------------
Resolution: Won't Fix
> Wrapping RenderResponse causes ClassCastException
> -------------------------------------------------
>
> Key: PLUTO-238
> URL: https://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, PLUTO238-01.patch
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (PLUTO-238) Wrapping RenderResponse causes
ClassCastException
Posted by "Eric Dalquist (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/PLUTO-238?page=all ]
Eric Dalquist updated PLUTO-238:
--------------------------------
Attachment: CacheManagingDispatcherPortlet.java
> 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
>
>
> 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
[jira] Assigned: (PLUTO-238) Wrapping RenderResponse causes
ClassCastException
Posted by "Elliot Metsger (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/PLUTO-238?page=all ]
Elliot Metsger reassigned PLUTO-238:
------------------------------------
Assignee: Elliot Metsger
> 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
>
>
> 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
[jira] Updated: (PLUTO-238) Wrapping RenderResponse causes
ClassCastException
Posted by "Eric Dalquist (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/PLUTO-238?page=all ]
Eric Dalquist updated PLUTO-238:
--------------------------------
Attachment: CachingHttpServletResponse.java
> 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