Simon, your description pointed me in the right direction. I'm aware of the JSF lifecycle, but there is another thing I haven't recognized yet: As you said before, the HTTP header contains the ViewStates, however, I'm using _server_ side state saving!
I haven't yet figured out the problem, but if I - switch to client side state saving and - remove Trinidad, everything works fine. Ok, this can only be a temporary solution, I will continue searching for the real problem. Regards, Andreas Simon Kitching wrote: > > Hi Andy, > > You said that you were having problems with h:commandLink: > > > >> Some of the links do not work correctly, but i can't see any difference. >> If i click on some of the links (mostly MyFaces or Tomahawk >> commandLinks), I'm always getting the same error: >> >> /pages/xlist.jsp No saved view state could be found for the view >> identifier: /pages/xlist.jsp >> > > In JSF, an h:commandLink triggers a *form submit*. The general process is: > * restore view > * process all submitted values from the form > * validate all components > * update model for all components > * run the "action" associated with the commandLink (which usually > changes the current view) > * render the current view > > The "action" can be a literal string, in which case navigation occurs > using the defined nav rules. Or it can be a method, in which case that > method can do whatever it wants, then return a nav string. > > But as shown above, the very first thing that needs to be done is to > restore the view for the page that the commandLink is in. When "client > side state saving" is used, the view is stored in a hidden field in the > form. When "server side state saving", then the form just has a hidden > field containing a "key" to the relevant saved tree in the session's > view cache. > > From the "live headers" stuff below, a form submit does seem to be > happening. There are: > subFup=close > ..SUBMIT=1 > ViewState=... > > The presence of this ViewState field says that you are using *client > side* state saving, not server-side state saving. That means that the > NUMBER_OF_VIEWS_IN_SESSION setting is unused (views are stored in the > page, not the session). > > So the question now is why MyFaces Core can't restore the view from this > submitted field for some links on your pages. > > MyFaces does normally encrypt the ViewState hidden field by default, > then decrypt it on submit. by default it also generates a new random key > when restarted, which means that after restart browsers holding pages > rendered before the restart get an error. But (a) this doesn't seem to > match your description, and (b) the error usually says "Bad Padding" or > similar. > > I would check for any servlet filters in your app that might be doing > redirects or messing with the submitted form params. I can't currently > think of anything that would just affect *some* links in your app... > > Regards, > Simon > -- View this message in context: http://www.nabble.com/Tomahawk---Compatible-version-for-MyFaces-1.2.5-tp22311695p22436836.html Sent from the MyFaces - Users mailing list archive at Nabble.com.
