There is a basic assumption with JSF 2 that when resources (typically references to JavaScript files) are targetted at areas like "head" and "body" that the page contains the actual "h:head" and "h:body" tags respectively. Without these tags, the basic ICEfaces bridge code cannot be made available. However, we have other areas of the code (e.g. ice.captureSubmit, deltaSubmit) that can add inline scripts that rely on these core resource files being available. The end result is that the scripts can get added to the page but the main files are never loaded and the browser complains that some JavaScript references (e.g. "ice") are undefined and no ICEfaces functionality is available.

For portlets, the same basic logic holds true. Although portlets don't typically allow rendering directly to the head or body, it's the responsibility of the portlet bridge to override the standard JSF behaviour and use other means (potentially vendor specific means) to ensure that calls to render code to the head or body are handled appropriately.

It is possible to have ICEfaces available but not want to use it on certain pages - in other words, it should be possible to mix ICEfaces and non-ICEfaces pages together within one application or portlet .war file so we need to ensure that in cases where h:head and h:body tags are not available, we don't render out any scripts that rely on resources targetted to those areas.