Using a faces-config.xml file in the ICEFaces jar file to configure an ICEfaces friendly version of the StateManager is good, but adding a separate configuration entry to an application faces-config.xml file causes three instances of the StateManager to be created in a delegate chain. The state saving operations need not be chained, only one instance of an ICEfaces StateManager need do work, plus the JSF StateManager for some Stream based operations.

An approach will be to add the ability for our StateManager implementations to discover the StateManager hierarchy and to chose whether or not to do work or to strictly call the delegate based on whether any given instance is the default or an instance implemented by the Application author, which I'd presume would take priority.

This approach requires that all containers discover and read the faces-config.xml files in the same order, something we'll discover as we go along.