[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019640#comment-13019640
 ] 

Scott O'Bryan commented on PORTLETBRIDGE-211:
---------------------------------------------

Cool.  I found a way to move this.  :)

With the latest Trinidad 2.0.0-beta-3 (which will probably be release soon as 
Trinidad 2.0.0), I was able to run the TCK with the Trinidad jars included.  
The PPR tests are still failing for an unknown reason, but it looks like the 
Trinidad code is doing the right thing and the breakage is happening in the 
R.I.  (Not sure how it's even getting there but it is).

The full stack trace I'm seeing is as follows:

Apr 13, 2011 6:14:57 PM org.apache.catalina.core.ApplicationContext log
SEVERE: Exception thrown in doFacesRequest:resource
javax.faces.FacesException: java.lang.ClassCastException: 
org.apache.myfaces.trinidadinternal.config.xmlHttp.XmlHttpResourceResponse 
cannot be cast to javax.servlet.http.HttpServletResponse
        at 
org.apache.myfaces.shared_portlet.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241)
        at 
org.apache.myfaces.shared_portlet.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156)
        at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
        at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
        at 
org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRender(BridgeImpl.java:1068)
        at 
org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:1209)
        at 
javax.portlet.faces.GenericFacesPortlet.doBridgeDispatch(GenericFacesPortlet.java:700)
        at 
javax.portlet.faces.GenericFacesPortlet.serveResource(GenericFacesPortlet.java:291)
        at 
org.apache.pluto.driver.services.container.FilterChainImpl.doFilter(FilterChainImpl.java:186)
        at 
org.apache.pluto.driver.services.container.FilterChainImpl.processFilter(FilterChainImpl.java:77)
        at 
org.apache.pluto.driver.services.container.FilterManagerImpl.processFilter(FilterManagerImpl.java:98)
        at 
org.apache.pluto.container.driver.PortletServlet.dispatch(PortletServlet.java:350)
        at 
org.apache.pluto.container.driver.PortletServlet.doPost(PortletServlet.java:267)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
        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.processRequest(ApplicationDispatcher.java:436)
        at 
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374)
        at 
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302)
        at 
org.apache.pluto.driver.container.DefaultPortletInvokerService.invoke(DefaultPortletInvokerService.java:229)
        at 
org.apache.pluto.driver.container.DefaultPortletInvokerService.serveResource(DefaultPortletInvokerService.java:149)
        at 
org.apache.pluto.container.impl.PortletContainerImpl.doServeResource(PortletContainerImpl.java:203)
        at 
org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:156)
        at 
org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:205)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
        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.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
        at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
        at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:558)
        at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
        at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
        at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
        at 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
        at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.ClassCastException: 
org.apache.myfaces.trinidadinternal.config.xmlHttp.XmlHttpResourceResponse 
cannot be cast to javax.servlet.http.HttpServletResponse
        at 
com.sun.faces.util.OnOffResponseWrapper.<init>(OnOffResponseWrapper.java:58)
        at 
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:94)
        at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)

> Trinidad doesn't work with the 3.0.0 Portlet Bridge
> ---------------------------------------------------
>
>                 Key: PORTLETBRIDGE-211
>                 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-211
>             Project: MyFaces Portlet Bridge
>          Issue Type: Bug
>          Components: TCK
>    Affects Versions: 3.0.0-alpha
>            Reporter: Michael Freedman
>            Assignee: Scott O'Bryan
>
> I got 2.0.0-alpha2 working with a patch but once I upgraded to 2.0.0-beta-2 
> (which fixed the problem I needed to patch) the bridge completely breaks as 
> long as the app includes the trinidad libs.  There seems to be some 
> incompatibilities between the Trinidad extensions and the bridge's.  Did get 
> a chance to track down the specific details but wanted to get the issue 
> logged as its likely to be identified much faster by someone in the Trinidad 
> team.
> To reproduce -- get the bridge-3.0.0-alpha and set up a project pointing to 
> the 3.0.0 TCK.  Follow the instructions in the TCK User Manual for building 
> it, configuring it on Apache, and then running it.  With the Trinidad jars in 
> the deployment you will find that almost all the test fail (>170) -- the few 
> that pass don't actually execute Faces.  If you remove the jars (and I think 
> drop the other Trinidad refs in the web.xml) things run fine except for those 
> few tests that depend on Trindiad (failed tests shoudl be something like 37).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to