Details
Bug
Major
Description
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.
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.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
The previous algorithm for state saving hierarchy detection (using a getWrapped method) didn't work in the Seam framework where, if there were a SingleCopyStateManagerImpl defined in the users faces-config file, you could get a delegate hierarchy like this:
JSF StateManagerImpl <- ViewRootStateManagerImpl <- SeamStateManagerImpl <- SingleCopyStateManagerImpl
This detail broke the original implementation because there's no way to follow the delegate chain through the Seam StateManager.
Show
Greg Dick
added a comment - The previous algorithm for state saving hierarchy detection (using a getWrapped method) didn't work in the Seam framework where, if there were a SingleCopyStateManagerImpl defined in the users faces-config file, you could get a delegate hierarchy like this:
JSF StateManagerImpl <- ViewRootStateManagerImpl <- SeamStateManagerImpl <- SingleCopyStateManagerImpl
This detail broke the original implementation because there's no way to follow the delegate chain through the Seam StateManager.
I've checked in some changes that, from the context of an ICEfaces StateManager implementation, if there is another ICEfacesStateSaving implementation configured higher up the delegate chain. If so, the StateManagerImpl will go into pure delegation mode and will not attempt to do any state saving at all.
This will address the situation where the ViewRootStateSavingImpl is configured in our faces-config.xml file but an application developer wants to override it with their own setting without first de-configuring our default one.