I've checked in an initial version of the files required to build a portlet version of the Component Suite application. This includes Ant and Maven build files. The portlet and Liferay configuration files are also included and I've set up 2 of the portlets for deployment - ACE Buttons and ACE Accordion Panel (both which appear to work).

There is still a fair amount of work to do, including:

• finishing the configuration files for all portlets
• fixing the menus to prevent full page navigation
• adjusting the styling so that the portlets fit more effectively on the page

There will be other issues related to actual functioning of the portlets but we can create separate JIRAs for these as needed.

Checked in updated configuration files so that all ACE and Compat examples are now available as portlets. In addition to the styling work above, there are some issues around non-portlet friendly classes/methods used in a couple of the examples (e.g. HttpSession). Details to be provided shortly.

It also appears that there is some YUI 3 code being used. This is a known conflict with Liferay's YUI usage and causes problems (like disabling the Liferay menus).

Going through the components now looking at more individual problems:

I've already created ICE-7226 to cover the use of non-portlet friendly API usage. Temporarily fixing that reveals another issue. When I click to export the table, the PortletFaces Bridge throws this:

21:36:33,672 ERROR [ExternalContextImpl:301]
java.lang.NullPointerException
at org.portletfaces.bridge.context.ExternalContextImpl.encodeBookmarkableURL(ExternalContextImpl.java:260)
at com.sun.faces.application.view.MultiViewHandler.getBookmarkableURL(MultiViewHandler.java:363)
at com.sun.faces.renderkit.html_basic.OutcomeTargetRenderer.getEncodedTargetURL(OutcomeTargetRenderer.java:166)
at com.sun.faces.renderkit.html_basic.OutcomeTargetLinkRenderer.renderAsActive(OutcomeTargetLinkRenderer.java:154)
at com.sun.faces.renderkit.html_basic.OutcomeTargetLinkRenderer.encodeBegin(OutcomeTargetLinkRenderer.java:92)
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:820)

The current way we are doing the exporting is not working in the portlet. The portlet lifecycle has a stricter division between various types of requests (Action vs Event vs Render vs Resource) and I believe the current failure is related to the Export button being triggering an Action when what we may really want is a Resource.

Checked in some changes to that each example is now configured to run as a separate portlet. We'll be going with this strategy until we can get the navigation issues fully resolved.

Did some testing and it looks like most stuff appears to be relatively functional but there are some issues. Since there are over 80 individual portlet examples, I obviously haven't run them all nor have they been tested in many combinations.

• Styling is better but still too wide.

• Some examples refer to the "menus on the left" which are not there when running in portlets.

• Interactions with some (non-navigation) examples are causing full page refreshes for some reason. ACE Context Menu with Table Integration and ACE Context Menu Effect are examples that do this.

• I can get the following under certain conditions when more than one portlet is on the page. Perhaps if examples are sharing the same Window bean (ACE Context Menu with Table and ACE Context Menu with Effect)?

Caused by: java.lang.IllegalStateException: Component ID A2232:j_idt85:j_idt85_windowviewid has already been found in the view.
at com.sun.faces.util.Util.checkIdUniqueness(Util.java:833)
at com.sun.faces.util.Util.checkIdUniqueness(Util.java:817)
at com.sun.faces.util.Util.checkIdUniqueness(Util.java:817)
at com.sun.faces.util.Util.checkIdUniqueness(Util.java:817)
at com.sun.faces.application.view.StateManagementStrategyImpl.saveView(StateManagementStrategyImpl.java:144)
at com.sun.faces.application.StateManagerImpl.saveView(StateManagerImpl.java:133)
at com.sun.faces.application.view.WriteBehindStateWriter.flushToWriter(WriteBehindStateWriter.java:225)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:418)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
... 194 more

• ACE File Entry blew chunks. Maybe be a difference in how the PortletFaces Bridge passes in certain parameters:

java.lang.NullPointerException
at org.icefaces.impl.context.DOMPartialViewContext.applyBrowserChanges(DOMPartialViewContext.java:351)
at org.icefaces.impl.context.DOMPartialViewContext.processPartial(DOMPartialViewContext.java:133)
at javax.faces.component.UIViewRoot.encodeChildren(UIViewRoot.java:981)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1757)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:390)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at org.portletfaces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:535)
at org.portletfaces.bridge.GenericFacesPortlet.serveResource(GenericFacesPortlet.java:131)
at com.liferay.portlet.FilterChainImpl.doFilter(FilterChainImpl.java:119)
at com.liferay.portal.kernel.portlet.PortletFilterUtil.doFilter(PortletFilterUtil.java:71)
at com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:92)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

• Menus are getting "clipped" within the container in some way so that you can't see all the choices.

• Tabset Proxy doesn't appear to work as content is not loaded into the tabs.

• ProgressBarPush bean has a non-portlet friendly API usage that I have fixed. I did a quick scan and there are a couple of other problematic calls in FacesUtils but I don't think they are actually being used anywhere.

Running the ACE Showcase with MyFaces in a non-portlet environment and examining the theme.css file for the resolved resources, they all seem to follow a consistent pattern. So perhaps is an interaction between MyFaces and the PortletFaces Bridge that is causing the problem:

url("/my/javax.faces.resource/themes/sam/images/ui-bg_flat_75_ffffff_40x100.png.jsf?ln=icefaces.ace")
url("/my/javax.faces.resource/themes/sam/images/ui-default.png.jsf?ln=icefaces.ace")
url("/my/javax.faces.resource/themes/sam/images/sprite.png.jsf?ln=icefaces.ace")

This is looking pretty complicated. I think what's happening is that there is an interaction between the PortletFaces Bridge and MyFaces when doing stream reading/writing of the CSS files that have EL tidbits in them.

In MyFaces, the work to read/indentify/replace the EL tags with the appropriate value is done in ResourceImpl by a special private class:

private class ValueExpressionFilterInputStream extends InputStream
{
private PushbackInputStream delegate;

public ValueExpressionFilterInputStream(InputStream in)

...

In the PortletFaces Bridge ResourceHandlerImpl, the resource reading and writing is relying on a couple of Channels:

// Copy the bytes in the resource's input stream to the response's output stream.
int responseContentLength = 0;
readableByteChannel = Channels.newChannel(inputStream);
writableByteChannel = Channels.newChannel(externalContext.getResponseOutputStream());

I don't have details yet but my theory is that the Channels are interacting with the underlying MyFaces pushback streams while they are in the process of evaluating and writing the EL expressions which leads to the very non-deterministic results we are seeing.

Couple of comments about how to make the current showcase more portlet friendly:

1) Adjust fixed width container

The main-template.xhtml has a div with an id called container. The style for this is specified in the demo_tempate.css file as:

#container

That wide of a container makes it inconvenient to drop multiple portlets into a page. Perhaps a percentage would be more appropriate.

2) CSS URL resources

Portlets rely on different URL semantics than normal web applications. The way we do it our theme.css file, where we use the 'resource' expression language tactic allows for the portlet bridge to make the appropriate adjustments to the resource URL:

url("#

"

The themes that we include with the showcase example use "raw" URLs. For example, in showcase_styles.css we have:

.ice-checkboxbutton .ui-state-active

where it would be better to do:

.ice-checkboxbutton .ui-state-active {
background: url("#

") no-repeat;
border: 1px;
border-style: solid;
}

A working version of the ACE showcase that runs in a portal container has been developed and made available. Any ACE issues specific to portlets can be captured in separate JIRAs moving forward.