I created this ticket:

http://jira.icefaces.org/browse/ICE-7168

Basically, icefaces is adding a handler via jsf.ajax.addOnEvent, which will get processed for ALL requests on the page even those coming from non-icefaces portlets. It would be ok, if it detected when the request was NOT from an icefaces form and failed gracefully allowing the actual request to complete and be handled by the non-icefaces requester.

This is an old JIRA and is closed because the original investigation was complete. Could you create a new JIRA that describes your use case and the problem you see? Is ICEfaces attempting to modify a non-ICEfaces form?

A little more investigation shows that this is done when icefaces registers an onEvent handler through a call to jsf.ajax.addOnEvent. Perhaps the handler method could fail gracefully if the configuration is not found that way the request could proceed and jsf ajax could work even with icefaces adding that handler? It seems that icefaces interfering with other non-icefaces content is a major design flaw.

Really? The only workaround is to: "Use ICEfaces everywhere."? This is a problem as I have a portal which mixes all kinds of portlets. Some are jsp, some jsf, and some jsf with icefaces. The problem is those that are just plain jsf have all of their ajax requests hijacked by icefaces. This is causing failures here:

function configurationOf(element) {
return detect(parents(element),
function(e)

).configuration;
}

Since the portlet did not have the icefaces jar, it did not inject the .configuration property that this method is looking for, so this function actually returns null and any attempt to make a call against the returned value will fail. Is there a way to tell icefaces to ignore this portlet? Or more to the point could you have icefaces only hijack the functions of portlets that have the icefaces jar in their lib?

Support for standard ajax is part of the overall support for partial page processing.