ICEfaces
  1. ICEfaces
  2. ICE-7190

Enable support for portlets with MyFaces 2

    Details

    • Assignee Priority:
      P2
    • Affects:
      Documentation (User Guide, Ref. Guide, etc.)

      Description

      In addition to official support for standard ICEfaces 2 applications running on MyFaces 2, we need to enable support for portlets.

        Issue Links

          Activity

          Deryk Sinotte created issue -
          Deryk Sinotte made changes -
          Field Original Value New Value
          Salesforce Case []
          Fix Version/s 2.1 [ 10241 ]
          Assignee Priority P2
          Assignee Deryk Sinotte [ deryk.sinotte ]
          Hide
          Deryk Sinotte added a comment -

          During the initial test run of the portlet version of Component Showcase, the application deployed without incident but when attempting to render the first portlets, I hit this:

          18:17:07,565 ERROR [jsp:154] java.lang.NullPointerException
          at org.apache.myfaces.context.servlet.FacesContextImpl.isPostback(FacesContextImpl.java:381)
          at org.portletfaces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:360)
          at org.portletfaces.bridge.GenericFacesPortlet.doView(GenericFacesPortlet.java:181)
          at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:328)
          at javax.portlet.GenericPortlet.render(GenericPortlet.java:233)
          at com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:101)
          at com.liferay.portal.kernel.portlet.PortletFilterUtil.doFilter(PortletFilterUtil.java:64)
          at com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:92)
          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 com.liferay.portlet.InvokerPortletImpl.invoke(InvokerPortletImpl.java:638)
          at com.liferay.portlet.InvokerPortletImpl.invokeRender(InvokerPortletImpl.java:723)
          at com.liferay.portlet.InvokerPortletImpl.render(InvokerPortletImpl.java:425)
          at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
          at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:377)

          The code responsible is:

          353 @Override
          354 public boolean isPostback()
          355 {
          356 assertNotReleased();
          357
          358 RenderKit renderKit = getRenderKit();
          359 if (renderKit == null)
          360

          { 361 // NullPointerException with StateManager, because 362 // to restore state it first restore structure, 363 // then fill it and in the middle of the two previous 364 // process there is many calls from _ComponentChildrenList.childAdded 365 // to facesContext.isPostback, and getViewRoot is null. 366 // 367 // Setting a "phantom" UIViewRoot calling facesContext.setViewRoot(viewRoot) 368 // to avoid it is bad, because this is work of RestoreViewExecutor, 369 // and theorically ViewHandler.restoreView must return an UIViewRoot 370 // instance. 371 // 372 // The problem with this is if the user changes the renderkit directly 373 // using f:view renderKitId param, the ResponseStateManager returned 374 // will be the one tied to faces-config selected RenderKit. But the usual 375 // method to check if a request is a postback, is always detect the param 376 // javax.faces.ViewState, so there is no problem after all. 377 String renderKitId = this.getApplication().getViewHandler().calculateRenderKitId(this); 378 RenderKitFactory factory = (RenderKitFactory) 379 FactoryFinder.getFactory(FactoryFinder.RENDER_KIT_FACTORY); 380 renderKit = factory.getRenderKit(this, renderKitId); 381 }

          382 return renderKit.getResponseStateManager().isPostback(this);
          383 }

          Some quick Googling in the PortletFaces forums turned up:

          http://www.portletfaces.org/community/forums/-/message_boards/view_message/80005

          I have an email into Neil regarding this issue.

          Show
          Deryk Sinotte added a comment - During the initial test run of the portlet version of Component Showcase, the application deployed without incident but when attempting to render the first portlets, I hit this: 18:17:07,565 ERROR [jsp:154] java.lang.NullPointerException at org.apache.myfaces.context.servlet.FacesContextImpl.isPostback(FacesContextImpl.java:381) at org.portletfaces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:360) at org.portletfaces.bridge.GenericFacesPortlet.doView(GenericFacesPortlet.java:181) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:328) at javax.portlet.GenericPortlet.render(GenericPortlet.java:233) at com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:101) at com.liferay.portal.kernel.portlet.PortletFilterUtil.doFilter(PortletFilterUtil.java:64) at com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:92) 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 com.liferay.portlet.InvokerPortletImpl.invoke(InvokerPortletImpl.java:638) at com.liferay.portlet.InvokerPortletImpl.invokeRender(InvokerPortletImpl.java:723) at com.liferay.portlet.InvokerPortletImpl.render(InvokerPortletImpl.java:425) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:377) The code responsible is: 353 @Override 354 public boolean isPostback() 355 { 356 assertNotReleased(); 357 358 RenderKit renderKit = getRenderKit(); 359 if (renderKit == null) 360 { 361 // NullPointerException with StateManager, because 362 // to restore state it first restore structure, 363 // then fill it and in the middle of the two previous 364 // process there is many calls from _ComponentChildrenList.childAdded 365 // to facesContext.isPostback, and getViewRoot is null. 366 // 367 // Setting a "phantom" UIViewRoot calling facesContext.setViewRoot(viewRoot) 368 // to avoid it is bad, because this is work of RestoreViewExecutor, 369 // and theorically ViewHandler.restoreView must return an UIViewRoot 370 // instance. 371 // 372 // The problem with this is if the user changes the renderkit directly 373 // using f:view renderKitId param, the ResponseStateManager returned 374 // will be the one tied to faces-config selected RenderKit. But the usual 375 // method to check if a request is a postback, is always detect the param 376 // javax.faces.ViewState, so there is no problem after all. 377 String renderKitId = this.getApplication().getViewHandler().calculateRenderKitId(this); 378 RenderKitFactory factory = (RenderKitFactory) 379 FactoryFinder.getFactory(FactoryFinder.RENDER_KIT_FACTORY); 380 renderKit = factory.getRenderKit(this, renderKitId); 381 } 382 return renderKit.getResponseStateManager().isPostback(this); 383 } Some quick Googling in the PortletFaces forums turned up: http://www.portletfaces.org/community/forums/-/message_boards/view_message/80005 I have an email into Neil regarding this issue.
          Hide
          Deryk Sinotte added a comment -

          Linking to parent MyFaces 2 compatibility case.

          Show
          Deryk Sinotte added a comment - Linking to parent MyFaces 2 compatibility case.
          Deryk Sinotte made changes -
          Link This issue depends on ICE-5868 [ ICE-5868 ]
          Hide
          Deryk Sinotte added a comment -

          Trying to run chat-portlet and I was confronted with:

          Caused by: java.lang.NullPointerException
             at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager.java:103)
             at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:185)
             at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
             at org.portletfaces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:402)

          There was also an error in BridgeFlashFactory related to trying to determine which implementation (Mojarra vs MyFaces) is being used. I opened a ticket with a patch: http://jira.portletfaces.org/browse/BRIDGE-260

          Upgrading to the latest MyFaces and PortletFaces Bridge snapshots seems to allow chat-portlet to render out correctly so I'll have to try component-showcase and see if that works then swap out libraries to see which one helps.

          Show
          Deryk Sinotte added a comment - Trying to run chat-portlet and I was confronted with: Caused by: java.lang.NullPointerException    at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager.java:103)    at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:185)    at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)    at org.portletfaces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:402) There was also an error in BridgeFlashFactory related to trying to determine which implementation (Mojarra vs MyFaces) is being used. I opened a ticket with a patch: http://jira.portletfaces.org/browse/BRIDGE-260 Upgrading to the latest MyFaces and PortletFaces Bridge snapshots seems to allow chat-portlet to render out correctly so I'll have to try component-showcase and see if that works then swap out libraries to see which one helps.
          Hide
          Deryk Sinotte added a comment -

          I upgraded to the current trunk version of the PortletFaces Bridge (portletfaces-bridge-2.0.2-SNAPSHOT.jar) and that seemed to improve things. I was then able to load up the Component Showcase portlet example and run successfully through most of the components. The exceptions are:

          • rich text editor fails because ckeditor.js doesn't load (404 Not Found)
          • charts image doesn't load (404 Not Found)
          • data export fails (404 - Could not find requested dynamic resource)
          • fild download fails (404 - Could not find requested dynamic resource)
          • progress bar (due to tight push loop as captured in http://jira.icefaces.org/browse/PUSH-144)

          Most seem related to resource loading so there seems to be a good possibility that there is a common issue. The push problem is already known and being looked at. There are also the usual styling issues but nothing different from any previous release.

          Show
          Deryk Sinotte added a comment - I upgraded to the current trunk version of the PortletFaces Bridge (portletfaces-bridge-2.0.2-SNAPSHOT.jar) and that seemed to improve things. I was then able to load up the Component Showcase portlet example and run successfully through most of the components. The exceptions are: rich text editor fails because ckeditor.js doesn't load (404 Not Found) charts image doesn't load (404 Not Found) data export fails (404 - Could not find requested dynamic resource) fild download fails (404 - Could not find requested dynamic resource) progress bar (due to tight push loop as captured in http://jira.icefaces.org/browse/PUSH-144 ) Most seem related to resource loading so there seems to be a good possibility that there is a common issue. The push problem is already known and being looked at. There are also the usual styling issues but nothing different from any previous release.
          Hide
          Deryk Sinotte added a comment -

          So I switched back to Mojarra and the same problems with dynamic resources are present there as well. Looks like some change since the 2.0.2 release has messed up this processing. Attaching screenshot that shows resources for the ckeditor.js file and the chart image throwing the 404 status.

          Show
          Deryk Sinotte added a comment - So I switched back to Mojarra and the same problems with dynamic resources are present there as well. Looks like some change since the 2.0.2 release has messed up this processing. Attaching screenshot that shows resources for the ckeditor.js file and the chart image throwing the 404 status.
          Deryk Sinotte made changes -
          Attachment dynamic-portlet-resources.png [ 13709 ]
          Hide
          Deryk Sinotte added a comment -

          Going back to the beta, the problem manifests there as well but not in the 2.0.2 release.

          Show
          Deryk Sinotte added a comment - Going back to the beta, the problem manifests there as well but not in the 2.0.2 release.
          Hide
          Deryk Sinotte added a comment -

          So for the broken portlet resourcing, it appears to be related to a significant change to the DynamicResourceDispatcher. Revision 24940 appears to work as long as there is a small change made to Util to guard against null content types:

          public static boolean shouldCompress(String contentType) {
          if(contentType == null)

          { return false; }

          But 24941, where the big change to DynamicResourceDispatcher is made, fails to find the various resources that seem to be causing the problem. The JIRA that this work was done in is ICE-6931.

          Show
          Deryk Sinotte added a comment - So for the broken portlet resourcing, it appears to be related to a significant change to the DynamicResourceDispatcher. Revision 24940 appears to work as long as there is a small change made to Util to guard against null content types: public static boolean shouldCompress(String contentType) { if(contentType == null) { return false; } But 24941, where the big change to DynamicResourceDispatcher is made, fails to find the various resources that seem to be causing the problem. The JIRA that this work was done in is ICE-6931 .
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #26120 Fri Oct 28 09:28:49 MDT 2011 deryk.sinotte ICE-7190: update PortletFaces Bridge and add ProxySession to allow dynamic resources that are session-scoped to work properly with portlets
          Files Changed
          Commit graph DEL /icefaces2/trunk/icefaces/lib/portlets/portletfaces-bridge-2.0.1.jar
          Commit graph ADD /icefaces2/trunk/icefaces/lib/portlets/portletfaces-bridge-2.0.2-SNAPSHOT.jar
          Commit graph MODIFY /icefaces2/trunk/icefaces/core/src/main/java/org/icefaces/util/EnvUtils.java
          Commit graph MODIFY /icefaces2/trunk/icefaces/core/src/main/java/org/icefaces/impl/push/DynamicResourceDispatcher.java
          Commit graph ADD /icefaces2/trunk/icefaces/core/src/main/java/org/icefaces/impl/push/servlet/ProxySession.java
          Repository Revision Date User Message
          ICEsoft Public SVN Repository #26122 Fri Oct 28 09:42:05 MDT 2011 deryk.sinotte ICE-7190: remove Override annotation for interface implementation
          Files Changed
          Commit graph MODIFY /icefaces2/trunk/icefaces/core/src/main/java/org/icefaces/impl/push/servlet/ProxySession.java
          Hide
          Deryk Sinotte added a comment -

          So the changes to the DynamicResourceDispatcher were relying on storage in the session for keeping a reference to the session based dispatcher. Unfortunately, the ExternalContext.getSessionMap() method returns the PORTLET-scoped session map which differs from portlet to portlet and there is no way to directly access the APPLICATION-scoped session in the JSF API. So I created a ProxySession that uses reflection to access the method we want when faced with storing things in the session. We use the same proxy approach in other areas for requests and responses.

          By adding this new ProxySession and updating the PortletFaces Bridge to the latest 2.0.2 SNAPSHOT, it solves nearly all the issues with resources noted above. The exception is that the CKEditor still appears to have some issues. There have been recent changes in this area (ICE-7293) to support not having the CKEditor resources loaded proactively unless desired. These changes seem to impact the use of the editor in portlets so this still requires investigation.

          Show
          Deryk Sinotte added a comment - So the changes to the DynamicResourceDispatcher were relying on storage in the session for keeping a reference to the session based dispatcher. Unfortunately, the ExternalContext.getSessionMap() method returns the PORTLET-scoped session map which differs from portlet to portlet and there is no way to directly access the APPLICATION-scoped session in the JSF API. So I created a ProxySession that uses reflection to access the method we want when faced with storing things in the session. We use the same proxy approach in other areas for requests and responses. By adding this new ProxySession and updating the PortletFaces Bridge to the latest 2.0.2 SNAPSHOT, it solves nearly all the issues with resources noted above. The exception is that the CKEditor still appears to have some issues. There have been recent changes in this area ( ICE-7293 ) to support not having the CKEditor resources loaded proactively unless desired. These changes seem to impact the use of the editor in portlets so this still requires investigation.
          Ken Fyten made changes -
          Salesforce Case []
          Fix Version/s 2.1-Beta2 [ 10294 ]
          Ken Fyten made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Affects [Documentation (User Guide, Ref. Guide, etc.)]
          Resolution Fixed [ 1 ]
          Deryk Sinotte made changes -
          Link This issue depends on PUSH-144 [ PUSH-144 ]
          Ken Fyten made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Deryk Sinotte
              Reporter:
              Deryk Sinotte
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: