Attaching a screenshot showing the errors in Chrome from the initial load of the page. It should be noted that the conflict doesn't stop the ICEfaces component from working but it does seem to disable the Liferay UI so that, for example, adding additional portlets to the page is disabled.

Running showcase-portlet on Liferay 5.2.3 gives me lots of exceptions:

15:18:15,389 ERROR [jsp:?] org.portletfaces.bridge.BridgeException: java.lang.NullPointerException
org.portletfaces.bridge.BridgeException: java.lang.NullPointerException
at org.portletfaces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:547)
at org.portletfaces.bridge.GenericFacesPortlet.serveResource(GenericFacesPortlet.java:131)
at com.sun.portal.portletcontainer.appengine.filter.FilterChainImpl.doFilter(FilterChainImpl.java:177)
at com.liferay.portal.kernel.portlet.PortletFilterUtil.doFilter(PortletFilterUtil.java:76)
at com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:100)
.......
.......

The exceptions seem to correspond to the requested JS and CSS resources, all responses are HTTP 500 without any message in the response boy.

I have a patch waiting for this issue (captured in ICE-7718) to commit to the trunk once we've released. It's just some null checking that needs to be done. You can add it yourself if you like to keep going on the issue.

Index: core/src/main/java/org/icefaces/application/ResourceRegistry.java
===================================================================
— core/src/main/java/org/icefaces/application/ResourceRegistry.java (revision 27529)
+++ core/src/main/java/org/icefaces/application/ResourceRegistry.java (revision )
@@ -190,13 +190,17 @@
private static String extractResourceId(FacesContext facesContext) {
ExternalContext externalContext = facesContext.getExternalContext();

• int markerStart;
  + int markerStart = -1;
  String path = externalContext.getRequestServletPath();
  + if( path != null ) { - markerStart = path.indexOf(RESOURCE_PREFIX); + markerStart = path.indexOf(RESOURCE_PREFIX); + }

  if (-1 == markerStart)

  Unknown macro: { path = externalContext.getRequestPathInfo();+ if( path != null ){ - markerStart = path.indexOf(RESOURCE_PREFIX); - }+ markerStart = path.indexOf(RESOURCE_PREFIX);+ }

  + }

//With Liferay, the reference to javax.faces.resource gets set to a parameter rather than
//part of the URL so we need a slightly different algorithm.

In core.js invoked JQuery.noConflict with 'true' value as parameter to make sure both window.$ and window.jQuery global variables are restored to the previously loaded jQuery version.

noConflict(true) has wide reaching effects on the availability of the global JQuery object required in several components / plugins.

When not using compressed resources, a DataTable example page from the showcase presents the following JS errors:

ace-jquery.js.jsf:20281 - Uncaught TypeError: Cannot read property 'fn' of undefined
ace-components.js.jsf:38 - Uncaught TypeError: Cannot read property 'ui' of undefined
ace-menu.js.jsf:17 - Uncaught TypeError: Cannot read property 'event' of undefined
ace-datatable.js.jsf:2316 - Uncaught TypeError: Property 'jQuery' of object [object DOMWindow] is not a function
2showcase.jsf:219 - Uncaught TypeError: undefined is not a function
showcase.jsf:360 - Uncaught TypeError: undefined is not a function

All of which are attempted references to features of the JQuery context or objects that would've been defined if previous errors had not occurred.

This change is being reverted until adaptations can be made or a new workaround discovered.

Fixed at revision 27865 in trunk and at revision 27866 in maintenance branch.

To fix the problem it was necessary to replace all references to the global 'jQuery' variable for 'ice.ace.jq', both in Javascript files and in renderers that generate javascript code.

It was also necessary to call jQuery.noConflict(true) to restore the '$' and 'jQuery' variables to their original values after having loaded the jQuery code for ACE components.

A fix for ICE-7701, related to the noConflict(true) call, caused the Javascript errors reported in this issue to show up again when using Liferay 5. One more modification to this fix finally solved all these problems for Liferay 5 and 6.

There are still some styling issues to solve that will be documented in a separate jira.