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

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.

Linking to parent MyFaces 2 compatibility case.

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.

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.

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.

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

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)

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.

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.