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

Reply via email to