My guess would be that the resource should be application scoped rather than session scoped since we always want this on to be there in this particular case.

Ted says:

If it really is just one file, it should be possible to serve it directly from the .jar as a standard JSF resource and not consider scope at all, and this can be served without considering scope whether the .js file needs to be referred to in the head or body of the document.

Adnan, please review and implement the suggested change, if feasible.

Also, memory requirements will be reduced by not allocating the JavaScript as a session resource.

This issue is caused by the recent changes to the ResourceRegistry, the resources are now session scoped so they can be easily discarded when the session expires. The rich text resource registration still assumes that the resources are application scoped.

The fix changed the resource registration by registering the same resource object for each session. After the registration each session is marked to avoid re-registering the resources during each JSF lifecycle.

In the current client application I'm working on, I cleared the cache/cookies and was able to reproduce this issue. We have jars from August 25.

In Firefox javascript console:

"NetworkError: 404 Not Found - http://localhost:8080/1Line/icefaces/resource/LTE5NDk5MzQyNTU=//ckeditor.js"

I could not reproduce the issue anymore. Waiting for the all the sessions to expire and then accessing the application with the browser with all its cookies cleared yielded successful results.

Brad, have you rebuilt also icefaces-compat.jar before testing?

I just ran the original problem scenario using the latest head revision:

URL: http://server.ice:8888/svn/ossrepo/icefaces2/trunk/icefaces
Repository Root: http://server.ice:8888/svn/ossrepo
Repository UUID: 8668f098-c06c-11db-ba21-f49e70c34f74
Revision: 25404
Node Kind: directory
Schedule: normal
Last Changed Author: mircea.toma
Last Changed Rev: 25403
Last Changed Date: 2011-09-05 09:06:11 -0700 (Mon, 05 Sep 2011)

And the behaviour seems fine now. Need to Brad to confirm that it's fixed or provide specific way to reproduce.

Could not reproduce this issue in the poc from Grimlock head using JSF 2.1.3 jars.

We'll need to ensure that this works on WebSphere for the next EE release. Part of the testing for Component Showcase must include clearing cache/cookies and reloading.

Some quick testing on Williams app (where the problem manifested) indicates that perhaps the extra slash in the resource URL is not handled in WebSphere. So rather than:

http://172.31.50.58:9080/1Line/icefaces/resource/LTE5NDk5MzQyNTU=//ckeditor.js

removing the extra slash in front of ckeditor.js works when typed in manually:

http://172.31.50.58:9080/1Line/icefaces/resource/LTE5NDk5MzQyNTU=/ckeditor.js

So in InputRichTextSetup:

public void processEvent(SystemEvent event) throws AbortProcessingException {
final FacesContext context = FacesContext.getCurrentInstance();
if (EnvUtils.isICEfacesView(context)) {
UIViewRoot root = context.getViewRoot();

UIOutput inputTextJS = new UIOutputWriter() {
public void encode(ResponseWriter writer, FacesContext context) throws IOException

};
inputTextJS.setTransient(true);
inputTextJS.setId("inpRichTxt");

root.addComponentResource(context, inputTextJS, "head");
}
}

I removed the extra slash as described above and tested it on Tomcat + Component Showcase with no ill effects. The change is now checked into the icefaces2/trunk