Really weird. As a wild guess, perhaps Trinidad's AJAX stuff forces client-side state-saving, and then when you do a non-ajax postback then things get confused because you have both server and client-side state?
It might be worth asking about that in a separate email thread, putting TRINIDAD in the subject... Regards, Simon andi303 schrieb: > 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 >> > -- -- Emails in "mixed" posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
