Details
Description
I added the following lines to the end of D2DViewHandler.writeState(FacesContext):
// javax.faces.render.ResponseStateManager.VIEW_STATE_PARAM
String ResponseStateManager__VIEW_STATE_PARAM = "javax.faces.ViewState";
Object pValue = context.getExternalContext().
getRequestParameterMap().get(ResponseStateManager__VIEW_STATE_PARAM);
System.out.println("pValue: " + pValue);
// The value com.sun.faces.application.StateManagerImpl uses
String LOGICAL_VIEW_MAP = "com.sun.faces." + "logicalViewMap";
Map logicalMap = (Map) context.getExternalContext().getSessionMap().get(LOGICAL_VIEW_MAP);
System.out.println("logicalMap: " + logicalMap);
I then clicked around in the component showcase several times, each time it printed out two lines:
pValue: j_id1:j_id2
logicalMap: {j_id1={j_id2=[Ljava.lang.Object;@f036de, j_id3=[Ljava.lang.Object;@c50443}}
pValue: j_id1:j_id2
logicalMap: {j_id1={j_id3=[Ljava.lang.Object;@c50443, j_id2=[Ljava.lang.Object;@f036de, j_id4=[Ljava.lang.Object;@1a6d5e1}}
pValue: j_id1:j_id2
logicalMap: {j_id1={j_id3=[Ljava.lang.Object;@c50443, j_id4=[Ljava.lang.Object;@1a6d5e1, j_id2=[Ljava.lang.Object;@f036de, j_id
5=[Ljava.lang.Object;@c5c0e5}}
pValue: j_id1:j_id2
logicalMap: {j_id1={j_id3=[Ljava.lang.Object;@c50443, j_id4=[Ljava.lang.Object;@1a6d5e1, j_id5=[Ljava.lang.Object;@c5c0e5, j_id
2=[Ljava.lang.Object;@f036de, j_id6=[Ljava.lang.Object;@1e1dfb2}}
pValue: j_id1:j_id2
logicalMap: {j_id1={j_id3=[Ljava.lang.Object;@c50443, j_id4=[Ljava.lang.Object;@1a6d5e1, j_id5=[Ljava.lang.Object;@c5c0e5, j_id
6=[Ljava.lang.Object;@1e1dfb2, j_id2=[Ljava.lang.Object;@f036de, j_id7=[Ljava.lang.Object;@163058b}}
pValue: j_id1:j_id2
logicalMap: {j_id1={j_id3=[Ljava.lang.Object;@c50443, j_id4=[Ljava.lang.Object;@1a6d5e1, j_id5=[Ljava.lang.Object;@c5c0e5, j_id
6=[Ljava.lang.Object;@1e1dfb2, j_id7=[Ljava.lang.Object;@163058b, j_id2=[Ljava.lang.Object;@f036de, j_id8=[Ljava.lang.Object;@15fd309}}
pValue: j_id1:j_id2
logicalMap: {j_id1={j_id3=[Ljava.lang.Object;@c50443, j_id4=[Ljava.lang.Object;@1a6d5e1, j_id5=[Ljava.lang.Object;@c5c0e5, j_id
6=[Ljava.lang.Object;@1e1dfb2, j_id7=[Ljava.lang.Object;@163058b, j_id8=[Ljava.lang.Object;@15fd309, j_id2=[Ljava.lang.Object;@f036de, j_id9=[Ljava.lang.Ob
ject;@1b8c5e3}}
Issue Links
- blocks
-
ICE-3842
InputFile state getting lost
-
- Closed
-
Activity
| Salesforce Case | [] | |
| Assignee Priority | P1 | |
| Assignee | Greg Dick [ greg.dick ] |
The regular Sun code synchronizes on the session object when accessing the session map. This sample code doesn't do that, but I've only ran it with a single view, so it shouldn't be a problem for this Jira. It might explain some of the weirdness for ICE-3842, since that does lifecycles on another thread. But even then, I don't think things would overlap.
| Salesforce Case | [] | |
| Fix Version/s | 1.8DR#2 [ 10142 ] |
This may be an issue with the JSF implementation. In a simple testcase I see the same behaviour in pure JSF. A search through the codebase shows no resetting of the session based LRUMap. From the JSF source
// Server Side state saving is handled stored in two nested LRU maps
// in the session.
//
// The first map is called the LOGICAL_VIEW_MAP. A logical view
// is a top level view that may have one or more actual views inside
// of it. This will be the case when you have a frameset, or an
// application that has multiple windows operating at the same time.
// The LOGICAL_VIEW_MAP map contains
// an entry for each logical view, up to the limit specified by the
// numberOfViewsParameter. Each entry in the LOGICAL_VIEW_MAP
// is an LRU Map, configured with the numberOfViewsInLogicalView
// parameter.
//
// The motivation for this is to allow better memory tuning for
// apps that need this multi-window behavior.
I'm not sure it's actually being implemented like that. The logging output seems to show increasing hashmap contents for a given view rather than the capability to store a single key for multiple views.
In any event, this behaviour is in common JSF code that we invoke from our instance of ViewHandler, and the object synchronization mentioned above is also contained within the JSF code we invoke. At this stage, I don't think there's anything wrong with the state saving implementation.
Perhaps, for this Jira, we should bring our findings to the attention of the Mojarra team, by filing a bug entry in their system, showing the behaviour in the stock JSF application.
| Repository | Revision | Date | User | Message |
| ICEsoft Public SVN Repository | #17994 | Fri Dec 05 15:04:56 MST 2008 | greg.dick | |
| Files Changed | ||||
MODIFY
/icefaces/trunk/icefaces/core/src/com/icesoft/faces/renderkit/dom_html_basic/FormRenderer.java
|
| Repository | Revision | Date | User | Message |
| ICEsoft Public SVN Repository | #17995 | Fri Dec 05 15:05:26 MST 2008 | greg.dick | |
| Files Changed | ||||
|
MODIFY
/icefaces/trunk/icefaces/core/src/com/icesoft/faces/context/DOMResponseWriter.java
|
JSF is keeping a history of the state saved views for back button navigation. On pressing the back button, the browser will replace the current page with a historical version of the page without any server interaction, and the old viewState keys are still valid - up to 15, which is the compile time limit on the LinkedHashMap that contains them.
There is a run time context param that defines how large this map is to be.
com.sun.faces.numberOfLogicalViews
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
| Fix Version/s | 1.8 [ 10161 ] | |
| Assignee Priority | P1 |
| Status | Resolved [ 5 ] | Closed [ 6 ] |
| Assignee | Greg Dick [ greg.dick ] |
The number of entries is limited to the most recent 15, which I think is JSF default limit for number of views in a session.