Hi Andy, You said that you were having problems with h:commandLink:
<quote> 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 </quote> 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 andi303 schrieb: > Simon, > Thanks again for your help! > > I've spend most of the last two days to find the problem, but without > success... > > - I'm only using one browser window. > - I've no custom JavaScript on the page, only those from Tomahawk and > RichFaces > - I've tried to change the context-param > org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION to a higher value, however, > this doesn't change anything. > - I'm not sure with that jsf_view_id thing you've mentioned. Here is the > output from "live http headers" content: > j_id_jsp_1011870818_22%3AxlistDataTable%3A0%3AsubFup=close&j_id_jsp_1011870818_22_SUBMIT=1&javax.faces.ViewState=ZpeMYvZXeBD6wSJfx8QdBJaMWkGJaIJBuce1WLpZUVMkhStvHv5n1XOQEsQdqkqtYDU3DRfOViFXdldNETvqf%2Bh3dsFtW%2FzvoYhKj3z%2F%2F2kEmfOZziQa0Q%3D%3D&j_id_jsp_1011870818_22%3A_idcl=j_id_jsp_1011870818_22%3AxlistDataTable%3A3%3Aj_id_jsp_1011870818_32 > > Maybe I understand things wrong: Why is there a saved view state of the > link? I've never visited this link before... > > I would be very happy if you have some further suggestions. > > Regards, Andreas > > > Simon Kitching wrote: >> Hmm. >> >> I presume you are using server-side state-saving here. >> >> Are you using multiple browser windows at the same time? Myfaces keeps a >> cache of the last N views in the session. Therefore if you perform N+1 >> submits using one window, then try to use the other window you will get >> this problem. Unfortunately there is no easy solution for this. Note >> that the value N is configurable; I think it defaults to 20. >> >> Otherwise, I suggest using the firefox "live http headers" plugin or >> similar to see what is actually being submitted to the server. There >> should be one field named "jsf_view_id" or similar; this contains the >> key to look up the saved viewstate. If this is missing for some reason >> (eg because of some custom javascript you have in your page) then that >> would cause this problem. >> >> I can't think of any other likely cause at the moment... >> >> Regards, >> Simon >> >