MyFaces Core
  1. MyFaces Core
  2. MYFACES-2395

Cant' run two JSF portlets on the same portal page

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.2.11, 2.0.8, 2.1.2
    • Component/s: Portlet_Support
    • Labels:
      None
    • Environment:
      JDK 1.5, JBoss AS 4.2.3, eXo PC 2.0.5 or eXO WCM 1.0 or eXO WCM 1.2

      Description

      Running two portlets in the same portal page, using JSF and the MyFaces Portlet Bridge (which is the RI for JSR-301, the JSF Portlet Bridge) yelds the error bellow for the second portlet:

      19:31:39,704 ERROR [portletcontainer] exception returned by processAction() or render() methods
      javax.portlet.PortletException: doBridgeDispatch failed: error from Bridge in executing the request
      at javax.portlet.faces.GenericFacesPortlet.doBridgeDispatch(GenericFacesPortlet.java:504)
      at javax.portlet.faces.GenericFacesPortlet.doRenderDispatchInternal(GenericFacesPortlet.java:456)
      at javax.portlet.faces.GenericFacesPortlet.doView(GenericFacesPortlet.java:231)
      at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:354)
      at javax.portlet.faces.GenericFacesPortlet.doDispatch(GenericFacesPortlet.java:202)
      at javax.portlet.GenericPortlet.render(GenericPortlet.java:259)
      at org.exoplatform.services.portletcontainer.plugins.pc.aop.PortletMethodCommand.render(PortletMethod Command.java:62)
      at org.exoplatform.services.portletcontainer.plugins.pc.aop.BaseCommandUnit.execute(BaseCommandUnit.java:46)
      ...
      Caused by: javax.portlet.faces.BridgeException: java.lang.ClassCastException: org.apache.myfaces.renderkit.RenderKitFactoryImpl
      at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRender(BridgeImpl.java:654)
      at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:544)
      at javax.portlet.faces.GenericFacesPortlet.doBridgeDispatch(GenericFacesPortlet.java:501)
      ... 63 more
      Caused by: java.lang.ClassCastException: org.apache.myfaces.renderkit.RenderKitFactoryImpl
      at org.apache.myfaces.shared_impl.renderkit.RendererUtils.getResponseStateManager(RendererUtils.java: 1158)
      at org.apache.myfaces.lifecycle.DefaultRestoreViewSupport.isPostback(DefaultRestoreViewSupport.java:127)
      at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:80)
      at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
      at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
      at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRender(BridgeImpl.java:640)
      ... 65 more

      This exception allways happen with the second portlet on the page, whichever it is. I tried with many portlets, but so you can reproduce the problem I'm attaching the wars for two very simple portlets.

      I'm filling this under MyFaces Core instead of Portlet Bridge because the same applications, if deployed to use Mojarra (included in JBoss AS 4.2) and the same portelt bridge jars, work fine.

      1. hora-mundo-jsf.war
        1.65 MB
        Fernando Silva Lozano
      2. todo-jsf.war
        1.66 MB
        Fernando Silva Lozano

        Activity

        Hide
        Fernando Silva Lozano added a comment -

        contact list porlet sample using JSF and configured for deployment on eXo Platform

        Show
        Fernando Silva Lozano added a comment - contact list porlet sample using JSF and configured for deployment on eXo Platform
        Hide
        Fernando Silva Lozano added a comment -

        sample world clock applicaton that uses jsf and is comfigured for deploy on eXo Platform

        Show
        Fernando Silva Lozano added a comment - sample world clock applicaton that uses jsf and is comfigured for deploy on eXo Platform
        Hide
        Leonardo Uribe added a comment -

        The problem here is because there are two myfaces implementations on the same classpath. We can't do too much here from myfaces side. In theory the solution is replace ri jars with myfaces ones in jboss application server, but I have never tried it. I have to close this one as invalid, because in fact that is a invalid configuration.

        Show
        Leonardo Uribe added a comment - The problem here is because there are two myfaces implementations on the same classpath. We can't do too much here from myfaces side. In theory the solution is replace ri jars with myfaces ones in jboss application server, but I have never tried it. I have to close this one as invalid, because in fact that is a invalid configuration.
        Hide
        Fernando Silva Lozano added a comment -

        I don't think this is a problem related to classpath. Maybe you was too quick in dismissing this bug. Do you have any evidence this isactually a classpath problem? Because my evidence tells it isn't.

        JBoss supports the use of alternative JSF implementations, provided inside the application WAR package. See that my both test apps include, on web.xml

        <context-param>
        <param-name>org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL</param-name>
        <param-value>true</param-value>
        </context-param>

        If you do that, JBoss bundled Mojarra is not visible inside the web app classloader.

        The jboss logs show that the MyFaces classes are being initialized for both apps. And the error stack traces does not includes any Mojarra classes, only MyFaces, eXo, Tomcat and JBoss AS ones, as expected.

        By the way other portal software don't support MyFaces, telling it won't work inside portlets without giving details. For example, Oracle iAS uses MyFaces as the bundled JSF implementation, but Oracle Portal states you have to use the Sun RI instead of MyFaces.

        I guess this is the issue behind supporting MyFaces on portlets, because everything I tried worked as long as there where only one JSF portlet on the same portal page. But nothing works when there are more than one, if I do use MyFaces.

        Show
        Fernando Silva Lozano added a comment - I don't think this is a problem related to classpath. Maybe you was too quick in dismissing this bug. Do you have any evidence this isactually a classpath problem? Because my evidence tells it isn't. JBoss supports the use of alternative JSF implementations, provided inside the application WAR package. See that my both test apps include, on web.xml <context-param> <param-name>org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL</param-name> <param-value>true</param-value> </context-param> If you do that, JBoss bundled Mojarra is not visible inside the web app classloader. The jboss logs show that the MyFaces classes are being initialized for both apps. And the error stack traces does not includes any Mojarra classes, only MyFaces, eXo, Tomcat and JBoss AS ones, as expected. By the way other portal software don't support MyFaces, telling it won't work inside portlets without giving details. For example, Oracle iAS uses MyFaces as the bundled JSF implementation, but Oracle Portal states you have to use the Sun RI instead of MyFaces. I guess this is the issue behind supporting MyFaces on portlets, because everything I tried worked as long as there where only one JSF portlet on the same portal page. But nothing works when there are more than one, if I do use MyFaces.
        Hide
        Leonardo Uribe added a comment -

        Both portlet wars has myfaces on its WEB-INF/lib folder. The problem here is the classpath should be the same for all portlets, so in fact in this case we have two myfaces impls on the same classpath. The stack trace shows it:

        java.lang.ClassCastException: org.apache.myfaces.renderkit.RenderKitFactoryImpl

        Now take a look at:

        org.apache.myfaces.shared_impl.renderkit.RendererUtils.getResponseStateManager(RendererUtils.java: 1158)

        Says this:

        RenderKitFactory factory = (RenderKitFactory) requestMap.get(RENDER_KIT_IMPL);

        The only way this could happen is if other portlet has already set this param before. The failure is seen when the second portlet is rendered.

        Note the param:

        Show
        Leonardo Uribe added a comment - Both portlet wars has myfaces on its WEB-INF/lib folder. The problem here is the classpath should be the same for all portlets, so in fact in this case we have two myfaces impls on the same classpath. The stack trace shows it: java.lang.ClassCastException: org.apache.myfaces.renderkit.RenderKitFactoryImpl Now take a look at: org.apache.myfaces.shared_impl.renderkit.RendererUtils.getResponseStateManager(RendererUtils.java: 1158) Says this: RenderKitFactory factory = (RenderKitFactory) requestMap.get(RENDER_KIT_IMPL); The only way this could happen is if other portlet has already set this param before. The failure is seen when the second portlet is rendered. Note the param:
        Hide
        Leonardo Uribe added a comment -

        Note the param:

        org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL

        just prevent init RI but does not remove from the classpath (but that's enought for most applications).

        Show
        Leonardo Uribe added a comment - Note the param: org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL just prevent init RI but does not remove from the classpath (but that's enought for most applications).
        Hide
        Fernando Silva Lozano added a comment -

        How can all portlets need to have the same classpath, if by the spec each package (WAR file) has its own classloader?

        If you are correct I cannot have, on the same portal, two portlets using different JSF implementations. Actually I'll need to have the same release and implementation for any web framework on all portlets. For example I won't be able to have struts 1.2.7 on one portlet and struts 1.3.1 on another. But I could have this on servlet-based web apps.

        Maybe people from the Portlet Bridge subproject can tell if you are correct or not.

        Well, it won't hurt to remove mojarra and add myfaces to jboss lib just to see what happens. Thanks for the clarifications!

        Show
        Fernando Silva Lozano added a comment - How can all portlets need to have the same classpath, if by the spec each package (WAR file) has its own classloader? If you are correct I cannot have, on the same portal, two portlets using different JSF implementations. Actually I'll need to have the same release and implementation for any web framework on all portlets. For example I won't be able to have struts 1.2.7 on one portlet and struts 1.3.1 on another. But I could have this on servlet-based web apps. Maybe people from the Portlet Bridge subproject can tell if you are correct or not. Well, it won't hurt to remove mojarra and add myfaces to jboss lib just to see what happens. Thanks for the clarifications!
        Hide
        Leonardo Uribe added a comment -

        I checked it again and the right thing to do is get RenderKitFactory just once in each place it is used, and deprecate this method. Anyway, I changed the code so now it use FacesContext attribute map. In 1.2 version I add an additional instanceof to check that case and if it is found recalculate the renderkit and prevent the bug (I don't know why I didn't do that before! maybe too focus on explain why that setup was not working).

        Show
        Leonardo Uribe added a comment - I checked it again and the right thing to do is get RenderKitFactory just once in each place it is used, and deprecate this method. Anyway, I changed the code so now it use FacesContext attribute map. In 1.2 version I add an additional instanceof to check that case and if it is found recalculate the renderkit and prevent the bug (I don't know why I didn't do that before! maybe too focus on explain why that setup was not working).

          People

          • Assignee:
            Leonardo Uribe
            Reporter:
            Fernando Silva Lozano
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development