Details
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
Greg Dick
created issue -
Greg Dick
made changes -
Field | Original Value | New Value |
---|---|---|
Assignee | Greg Dick [ greg.dick ] |
Greg Dick
made changes -
Salesforce Case | [] | |
Fix Version/s | 1.8 [ 10161 ] |
Repository | Revision | Date | User | Message |
ICEsoft Public SVN Repository | #18389 | Fri Feb 20 15:52:43 MST 2009 | greg.dick | |
Files Changed | ||||
MODIFY
/icefaces/trunk/icefaces/core/src/com/icesoft/faces/application/SingleCopyStateManagerImpl.java
MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/application/ViewRootStateManagerImpl.java |
Greg Dick
made changes -
Status | Open [ 1 ] | Resolved [ 5 ] |
Resolution | Fixed [ 1 ] |
Repository | Revision | Date | User | Message |
ICEsoft Public SVN Repository | #18401 | Mon Feb 23 10:48:52 MST 2009 | greg.dick | |
Files Changed | ||||
MODIFY
/icefaces/trunk/icefaces/core/src/com/icesoft/faces/application/SingleCopyStateManagerImpl.java
MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/application/ViewRootStateManagerImpl.java |
Ken Fyten
made changes -
Fix Version/s | 1.8RC2 [ 10163 ] | |
Fix Version/s | 1.8 [ 10161 ] |
Ken Fyten
made changes -
Fix Version/s | 1.8 [ 10161 ] |
Ken Fyten
made changes -
Status | Resolved [ 5 ] | Closed [ 6 ] |
Assignee | Greg Dick [ greg.dick ] |
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.