On 04/23/2010 04:25 PM, Rossen Stoyanchev wrote:
Hi-
I can confirm I no longer see the issue recorded in PLUTO-591. Thanks
for the quick fix!
Good to hear, I resolved the issue as fixed.
I now see another issue. I don't think is related to Pluto but I'll
paste it here anyway in case someone has an idea:
Caused by: java.lang.ClassCastException:
org.apache.pluto.container.impl.RenderResponseImpl cannot be cast to
javax.servlet.ServletResponse
at
com.sun.facelets.FaceletViewHandler.createResponseWriter(FaceletViewHandler.java:370)
at
com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:571)
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)
Rendering is based on Facelets (not JSP's) and the Sun JSF Portlet
bridge is version 1.2.5.
That is a typical mistake made by portlet bridge solutions which assume a
PortletRequest/Response is extending ServletRequest/Response.
Pluto 1.x actually implemented it in that way (and a lot of other portlet
containers).
However the portlet spec doesn't require that at all, and with the implementation for Portlet Spec 2.0 (which is a lot more demanding) we
discovered that extending ServletRequest/ServletResponse for the implementation of the PortletRequest/PortletResponse in fact causes many
(logical) problems practically impossible to solve.
So, Pluto 2.x no uses "cleanroom" implementations of PortletRequest/PortletResponse and you cannot cast them anymore to
ServletRequest/ServletResponse.
This therefore really needs to be solved by the Sun JSF Portlet bridge.
Regards,
Ate
Thanks,
Rossen
