To help verify that ResourceOrdering is the issue, I tweaked the code so that, when running MyFaces, we skip any processing of jsf.js and this appeared to allow the script resources to load and evaluate more normally.

if( EnvUtils.isMyFaces() && name != null && name.startsWith("jsf."))

else{
if (resourceEntry.name.equals(name) && resourceEntry.library.equals(library))

}

However, since this isn't likely to be a "real" fix, I'll turn this over to Mircea to have a look.

Screen shot showing the resource issues when running with MyFaces.

Carmen reports:

Using the nightly EE builds from jenkins (showcase with myFaces), this issue appeared first time on November 19th (Build # 93):

Build of December 17 (Build #90) - one JS error when loading showcase in any browser (IPCK-422 open for this issue).
Build of December 18 (Build # 91) - no issues.
Build of December 18 (Build # 92): showcase cannot be loaded in a browser due to an HTTP 500 error.
Build of December 19 (Build # 93): myfaces reordering issues.

FYI:

The same JS errors.

Carmen

On 04/01/2013 12:38 PM, Deryk Sinotte wrote:
For build #93, if you set the following context parameter, does it work better?

<context-param>
<param-name>org.icefaces.uniqueResourceURLs</param-name>
<param-value>false</param-value>
</context-param>

The resource ordering wasn't matching the resources that had their library name changed during ICE-8666 refactoring, because of that they were treated as resources without any specific dependency (and consequently added last).

Updated the resource library names for the ICEfaces core, compat and ICEpush resources in the resource-dependency.xml metadata.

Yes, I committed the change for datetimeentry.js by mistake. I reverted the last change for this file.

Re-opening this JIRA, due to the following new regression failures:

Icefaces3.0 trunk revision# 32964
Server: tomcat6
Browser: FF3.6/FF17, IE7 & GoogleChrome23

1) ICE-6080 & ICE-7019 - both regressions fail due to a JS error (all browsers), also when testing manually (MyFaces specific issue):
In FF the error is:
TypeError: window.ice is undefined
http://10.18.39.169:8080/ICE-6080/javax.faces.resource/icefaces-compat.uncompressed.js.jsf?ln=ice.compat&v=3_3_0_130107
Line 7057

2) In showcase sample app, clicking on the links to access ace:gMap or ace:richTextEntry - triggers an HTTP 500 error (myFaces specific):
root cause
java.lang.NullPointerException
javax.faces.application.Resource.setResourceName(Resource.java:83)
org.icefaces.impl.application.VersionedResource.<init>(VersioningResourceHandler.java:145)
org.icefaces.impl.application.VersioningResourceHandler.createResource(VersioningResourceHandler.java:72)
javax.faces.application.ResourceHandlerWrapper.createResource(ResourceHandlerWrapper.java:50)
org.icefaces.impl.push.servlet.ICEpushResourceHandler.createResource(ICEpushResourceHandler.java:115)
javax.faces.application.ResourceHandlerWrapper.createResource(ResourceHandlerWrapper.java:50)
javax.faces.application.ResourceHandlerWrapper.createResource(ResourceHandlerWrapper.java:50)

Attaching screen shot with the window.ice undefined JS error (ICE-6080 & ICE-7019).

1) The issue was mainly caused by icefaces-compat.uncompressed.js resource dependency data, the library name was the empty string while it should have been "ice.compat".
But this problem prompted me to understand why icefaces-compat.uncompressed.js wasn't added last even when its resource dependency data was missing (or not matching). It turned out the resources without dependency data were not first removed from view root but just re-added after the ordered resources were put in.

So ResourceOrdering.orderResources method was modified to make sure that the resource components that do not have resource dependency data to first remove them from the view root and then added last after the ordered resource components were put in.
Also modified BridgeSetup and ExtrasSetup to provide "name" and "library" attributes to the components responsible for renedering the bridge and compat setup code. Defined dependency data for the setup code.

2) Modified ace and compat GMapResourceHandler.ResourceEntry implmentation to return corresponding resource and library name when Resource.getResourceName or Resource.getLibraryName methods are invoked.

At rev# 33005, the 'window.ice' JS error and ace:gMap HTTP 500 error have been resolved; the Http 500 error still exists for ace:richTextEntry.

New issue with ace:richTextEntry is tracked under ICE-8864.