The following JavaScript reference is inserted for non-ICEfaces pages:

<script type="text/javascript" src="/basic/javax.faces.resource/bridge.js.jsf">

<script type="text/javascript">ice.onLoad(function() { try {document.body.bridge = ice.Application({blockUI: false,session: '7398CBFA84C9E77650124474F2243EF6',connection: {heartbeat: {},context: {current: '/basic/',async: '/basic/'}},messages: {sessionExpired: 'User Session Expired',connectionLost: 'Network Connection Interrupted',serverError: 'Server Internal Error',description: 'To reconnect click the Reload button on the browser or click the button below',buttonText: 'Reload'}},document.body); } catch (e)

; });</script>

More seriously, however, when icefaces.jar is included:

Error emptyResponse

is displayed in a JavaScript alert for any Ajax interaction.

Should test the basic Ajax example to verify ICEfaces/standard Ajax compatibility.

Next step is to create automated testing for this simple application.

Test(s) written and run (all passed). Application had to be altered (web.xml) to run with current jsf2.0 and ICEfaces2.0. See readme file for directions on how to run the tests with the Selenium IDE. Tests are located in added test subdirectory under project.

A test specifically aimed at testing the f:ajax tag both with and without ICEfaces has been checked into glimmer/samples/tests/fajax.

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

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?

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.

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?

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.