As what Martin Gaintly already replied, the problem is not within Pluto but in
the Sun's jsf-portlet bridge.
As the bridge is dispatching to the servlet level, it needs to deal with the
servlet api.
Although the portlet api layers on top of the servlet api, the HttpServletPortletResponseWrapper has to honor the servlet spec which says
reponse.getOutputStream() returns a ServletOutputStream, not a plain OutputStream.
So, this is clearly a bug in the jsf-portlet bridge (or whatever else is in
between).
Ate
On 04/21/2010 10:37 AM, rstoyanchev wrote:
Hi, I am attempting to use Sun's jsf-portlet integration with Pluto 2.0. I
get the following:
Caused by: java.lang.ClassCastException:
com.sun.faces.portlet.ByteArrayWebOutputStream cannot be cast to
javax.servlet.ServletOutputStream
at
org.apache.pluto.container.impl.HttpServletPortletResponseWrapper.getOutputStream(HttpServletPortletResponseWrapper.java:234)
at
org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:792)
at
org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:339)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:551)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:488)
at
org.apache.pluto.container.impl.PortletRequestDispatcherImpl.doDispatch(PortletRequestDispatcherImpl.java:174)
at
org.apache.pluto.container.impl.PortletRequestDispatcherImpl.include(PortletRequestDispatcherImpl.java:227)
at
com.sun.faces.portlet.ExternalContextImpl.dispatch(ExternalContextImpl.java:147)
at
org.springframework.faces.webflow.ExternalContextWrapper.dispatch(ExternalContextWrapper.java:25)
at
com.sun.faces.portlet.ViewHandlerImpl.executePageToBuildView(ViewHandlerImpl.java:371)
at
com.sun.faces.portlet.ViewHandlerImpl.renderView(ViewHandlerImpl.java:235)
at
org.springframework.faces.webflow.FlowViewHandler.renderView(FlowViewHandler.java:91)
at org.springframework.faces.webflow.JsfView.render(JsfView.java:89)
at
org.springframework.webflow.engine.ViewState.render(ViewState.java:282)
at
org.springframework.webflow.engine.ViewState.doEnter(ViewState.java:186)
at org.springframework.webflow.engine.State.enter(State.java:194)
at org.springframework.webflow.engine.Flow.start(Flow.java:535)
at
org.springframework.webflow.engine.impl.FlowExecutionImpl.start(FlowExecutionImpl.java:364)
at
org.springframework.webflow.engine.impl.FlowExecutionImpl.start(FlowExecutionImpl.java:222)
... 69 more
The JavaDocs for javax.portlet.MimeResponse indicates the
getPortletOutputStream() method return value is of type
java.io.OutputStream. Hence the cast to javax.servlet.ServletOutputStream in
HttpServletPortletResponseWrapper seems dodgy. Can you confirm if this is
indeed an issue with Pluto's implementation or not?
Thanks,
Rossen