Maven builds were required before Pluto testing could be done.

Pluto requires Maven poms because the maven-pluto-plugin needs to "massage" the web.xml file before the .war can be deployed to the portal container. Now that the Maven builds (including Pluto profiles) are available. It's possible to build and deploy to Pluto.

Early indications from the chat-portlet and the component-showcase-portlet examples indicates that things are working. The only issue I've seen from the preliminary testing is that the following issues are logged during every Ajax request:

13-Jan-2011 11:04:05 AM org.portletfaces.commons.logging.LoggerDefaultImpl error
SEVERE: There is no slash after the [javax.faces.resource] token in resourceURL=[/pluto/portal/CompShow01/__rscomponent-showcase-portlets0x2buttonsAndLinks!739165645%7C0/__ws0x3component-showcase-portlets0x2buttonsAndLinks!739165645%7C0_normal?stage=Development&javax.faces.resource=jsf.js&ln=javax.faces]
13-Jan-2011 11:04:05 AM org.portletfaces.commons.logging.LoggerDefaultImpl error
SEVERE: There is no slash after the [javax.faces.resource] token in resourceURL=[/pluto/portal/CompShow01/__rscomponent-showcase-portlets0x2buttonsAndLinks!739165645%7C0/__ws0x3component-showcase-portlets0x2buttonsAndLinks!739165645%7C0_normal?javax.faces.resource=icepush.js]
13-Jan-2011 11:04:05 AM org.portletfaces.commons.logging.LoggerDefaultImpl error
SEVERE: There is no slash after the [javax.faces.resource] token in resourceURL=[/pluto/portal/CompShow01/__rscomponent-showcase-portlets0x2buttonsAndLinks!739165645%7C0/__ws0x3component-showcase-portlets0x2buttonsAndLinks!739165645%7C0_normal?javax.faces.resource=bridge.js]
13-Jan-2011 11:04:05 AM org.portletfaces.commons.logging.LoggerDefaultImpl error
SEVERE: There is no slash after the [javax.faces.resource] token in resourceURL=[/pluto/portal/CompShow01/__rscomponent-showcase-portlets0x2buttonsAndLinks!739165645%7C0/__ws0x3component-showcase-portlets0x2buttonsAndLinks!739165645%7C0_normal?javax.faces.resource=compat.js]
13-Jan-2011 11:04:05 AM org.portletfaces.commons.logging.LoggerDefaultImpl error
SEVERE: There is no slash after the [javax.faces.resource] token in resourceURL=[/pluto/portal/CompShow01/__rscomponent-showcase-portlets0x2buttonsAndLinks!739165645%7C0/__ws0x3component-showcase-portlets0x2buttonsAndLinks!739165645%7C0_normal?javax.faces.resource=icefaces-compat.js]

I've gone through the component-showcase-portlets example running on Pluto in more detail with all the components. The current status is pretty good. Most things appear to work. There are some general styling issues - mostly due to the default font being fairly large and a fair amount of extra spacing but I wouldn't expect people to deploy their portal pages to the default Pluto theme normally. As for technical issues, I found the following:

1) As noted above, there is logging to indicate that resources aren't being handled/processed correctly. It appears that the PortletFaces Bridge is expecting javax.faces.resource to always end in a slash but that it can be delivered without. After discussing with Neil, I've created a JIRA in the PortletFaces system: http://jira.portletfaces.org/browse/BRIDGE-55.

2)The File Download component does not work. It throws an NullPointerException when attempting to download any of the sample files:

java.lang.NullPointerException
org.portletfaces.bridge.context.ExternalContextImpl.getResourceAsStream(ExternalContextImpl.java:868)
org.icefaces.application.showcase.view.bean.examples.component.outputResource.MyResource.open(OutputResourceBean.java:119)
com.icesoft.faces.component.outputresource.RegisteredResource.open(OutputResource.java:460)
com.icesoft.faces.context.ResourceRegistryLocator$DynamicResourceDispatcherAdapter$DynamicResourceAdapter.open(ResourceRegistryLocator.java:118)
org.icefaces.impl.push.DynamicResourceDispatcher$ResourceServer.respond(DynamicResourceDispatcher.java:225)
org.icefaces.impl.push.DynamicResourceDispatcher$ResourceServer.handleResourceRequest(DynamicResourceDispatcher.java:202)
org.icefaces.impl.push.DynamicResourceDispatcher$Mapping.handleResourceRequest(DynamicResourceDispatcher.java:371)
org.icefaces.impl.push.DynamicResourceDispatcher.handleResourceRequest(DynamicResourceDispatcher.java:90)
org.icefaces.application.ResourceRegistry.handleResourceRequest(ResourceRegistry.java:76)
org.icefaces.impl.application.WindowScopeManager.handleResourceRequest(WindowScopeManager.java:114)
javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:125)
javax.faces.application.ResourceHandlerWrapper.handleResourceRequest(ResourceHandlerWrapper.java:125)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:393)

The cause appears to be that the ExternalContext.release method is called and nulls our the internally referenced portletContext value. The portletContext is needed as it provides the underlying getResourceAsStream method. As a test, I commented out where this was set to null and everything worked fine. I'll need to discuss this with Neil as to the timing of the release call and why the portletContext is nulled out. Will create a JIRA if deemed necessary

3) The logging approach taken by the PortletFaces Bridge attempts to detect which logging library to use. Recent changes to the Log4J detection code seem to trigger classloading of log4j classes. Since neither Pluto or our examples include log4j, I saw a NoClassDefFoundException when attempting to deploy the sample application. The quick workaround was to simply include a log4j.jar with the sample app. Probably need a JIRA.

4) The selectInputText doesn't work. The drop down list of choices is never displayed. I can see in the Chrome console that the Ajax response is returned with the list of applicable values, but it's either not properly applied or not properly displayed. There were no errors so more investigation is required.

For other ACE portlets I get the same error as noted for FileEntry.

In addition to the logged ERROR noted above, for all ACE components the following stack trace is rendered out to the debugging output of the page:

java.lang.NullPointerException
at org.icefaces.apache.commons.fileupload.servlet.ServletFileUpload.isMultipartContent(ServletFileUpload.java:68)
at org.icefaces.component.fileentry.FileEntryPhaseListener.beforePhase(FileEntryPhaseListener.java:130)
at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:113)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at org.portletfaces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:232)
at org.portletfaces.bridge.GenericFacesPortlet.doView(GenericFacesPortlet.java:194)

The FileEntryPhaseListener (which appears to run regardless of whether of the actual component is used) is trying to reflectively call "getMethod" on a portlet request that doesn't support that method. Likely a simple check for null is required so that it can continue processing. With Liferay, the native implemenation of all their request may implement "getMethod" which would explain the difference in behaviour.

Looks like there is also a problem with YUI being properly downloaded and/or interpreted as I'm seeing some "YUI not defined" errors in the client.

For the YUI resources, the URL look like they may have an encoding issue compared to other resources that are being downloaded properly. My guess is that there some double-encoding being done as changing %252F to a simple '/' character allows the URL to work properly.

DOES NOT WORK:

http://localhost:8080/pluto/portal/ACE/__rsshowcase-portlet0x2slider!64611%7C0?javax.faces.resource=yui%252Fyui-min.js&ln=yui%252F3_1_1

WORKS:

http://localhost:8080/pluto/portal/ACE/__rsshowcase-portlet0x2slider!64611%7C0?javax.faces.resource=util.js&ln=org.icefaces.component.util

For the File Download (ice:ouputResource) issue described above, I created:

http://jira.portletfaces.org/browse/BRIDGE-56

The log4j issue has been cleaned up as per:

http://jira.portletfaces.org/browse/LOGGING-5

The outstanding compat issues that needs more research before a JIRA can be opened:

• the ice:selectInputText updates not being applied and/or rendered

The outstanding issues for ACE components are:

• the error being logged for setProperty which is likely us calling ExternalContext.setResponseStatus on a type of PortletResponse that does not support this operation
• the double-encoded YUI resource URLs

Just wanted to mention that all of the Pluto-related problems that were logged at http://jira.portletfaces.org were resolved in the bridge version 2.0.0-BETA4.

Tested chat-portlet and showcase-portlet from the branch for the impending 3.0.1/ EE 3.0 release. The chat-portlet worked fine. However, there is something not quite right with how the ACE portlets are rendered out in Pluto. They are including more content than they are configured to (e.g. Source Code streams) and therefore the content doesn't stay confined to the portlet containers. But they do appear to be functional. So while I wouldn't say the showcase example runs in Pluto as is, I'd say we could claim support for Pluto and I'm sure we can get the ACE showcase to behave better with some effort.

The problem appears to be a .pom/Maven issue. With the Ant build of showcase-portlet, we copy files over from the parent project (showcase) but "exclude" certain files so that the ones that we have customized for the portlets are used. These specific files are not handled with the Maven build currently so we end up with the templates and such from the parent project. This causes the full templating to be done and it tries to layout the full page with navigation and source code viewer within each portlet.

As it turned out to be a build issue, further testing on Pluto showed the showcase-portlets to be working on Pluto. Resolving as fixed.