-
1. Re: Diff in behaviour with STATE_SAVING changed to server fr
kevin.genie Jan 2, 2007 4:19 AM (in response to kevin.genie)Hello:
I forget to mention - the conversation is also same if you take the page again from the link in the case of STATE_SAVING = server.
Thanx
Kevin -
2. Re: Diff in behaviour with STATE_SAVING changed to server fr
kevin.genie Jan 5, 2007 1:01 AM (in response to kevin.genie)Hello:
Shall i report this in JIRA ? I feel that this issue is important because the behaviour should be same irrespective of the STATE_SAVING_METHOD, right ?
Thanx
Kevin. -
3. Re: Diff in behaviour with STATE_SAVING changed to server fr
norman.richards Jan 5, 2007 11:19 AM (in response to kevin.genie)Can you show some code that can reproduce this?
-
4. Re: Diff in behaviour with STATE_SAVING changed to server fr
kevin.genie Jan 31, 2007 10:32 AM (in response to kevin.genie)Hello:
Since this thread is old, let me say the problem again. If the STATE_SAVING_METHOD is changed to server from client and when a page is taken from a link second time , the first conversation and bean is not getting destroyed. I have a test case to reproduce this behaviour using the NumberGuess example.
1. Add a log or out.println message in the begin() method of NumberGuess.java
2. Deploy the NumberGuess example in Tomcat.
3. Give the web context url. U will get the numberGuess.seam page. Also, the log message that we have given in begin() will be printed in console.
4. In the same browser session, now refresh the page using browser refresh. The begin() will be called again and the log message also will be printed.
5. For every refresh in the same session, the begin() method will be called and you will get different conversations and different bean instances.
6. Now stop Tomcat. Change the state saving method in web.xml to server and make a clean new deployment. Copy commons-lang.jar (i used commons-lang-2.1.jar) to WEB-INF/lib for state saving with server. On repeating the steps 3 to 5, the begin() method is not being called for every refresh.
I have tested this behaviour with outputlinks in the page also and the behaviour is the same as described above. If you navigate to another page and then come back, then the create method is called and a new conversation also starts. If you request the current page again, then this behaviour is seen.
I have use Seam 1.0.1 GA and Tomcat 5.5.
Thanx,
Kevin. -
5. Re: Diff in behaviour with STATE_SAVING changed to server fr
gavin.king Jan 31, 2007 10:42 AM (in response to kevin.genie)Yes of course and that is what we have conversation timeouts for.
-
6. Re: Diff in behaviour with STATE_SAVING changed to server fr
kevin.genie Jan 31, 2007 11:05 AM (in response to kevin.genie)Hello Gavin,
I don't get you, Gavin. I think you have not read the posting fully or my posting is not clear.
What I tried to say was that there is a difference in behaviour in conversation start/end/propagation when the STATE_SAVING_METHOD is changed from client to server. When the STATE_SAVING_METHOD is server and when the current page is requested again (from an outputlink or thru browser refresh), a new conversation is not started and a new bean instance is not created which is OPPOSITE to the behaviour if the STATE_SAVING_METHOD is client.
Thanx,
Kevin. -
7. Re: Diff in behaviour with STATE_SAVING changed to server fr
gavin.king Jan 31, 2007 12:10 PM (in response to kevin.genie)That can *only* be due to a bug in your JSF implementation. I bet you are using an old version of the JSF impl.
-
8. Re: Diff in behaviour with STATE_SAVING changed to server fr
kevin.genie Feb 1, 2007 12:05 AM (in response to kevin.genie)Hello Gavin,
Sorry.. I didn't mentioned the MyFaces version. The NumberGuess 1.0.1 GA uses MyFaces 1.1.3 . I also tested with Seam 1.1 and MyFaces 1.1.4 and in both cases this behaviour exists.
Thanx,
Kevin. -
9. Re: Diff in behaviour with STATE_SAVING changed to server fr
gavin.king Feb 1, 2007 1:19 AM (in response to kevin.genie)I've confirmed this behavior. MyFaces does not rebuild the ViewRoot when you click refresh (unless you navigate to a different view id, and then use the backbutton).
This is a bug in MyFaces, since a non-faces request is supposed to build a new view, not restore an old one.
You should report it to the MyFaces team. -
10. Re: Diff in behaviour with STATE_SAVING changed to server fr
kevin.genie Feb 1, 2007 2:02 AM (in response to kevin.genie)Hello Gavin,
Thanks for the instant replies and confirmation.
I will post it to MyFaces forum and JIRA.
Thanx,
Kevin. -
11. Re: Diff in behaviour with STATE_SAVING changed to server fr
raghinii Feb 11, 2007 5:42 PM (in response to kevin.genie)
did you ever file a bug on this with myfaces ?
i can't find anything related in their JIRA or on the mailing list archive.
(i'm running into what i suspect is the same problem with
a restful application w/ page parameters and actions.)
thanks,
radu -
12. Re: Diff in behaviour with STATE_SAVING changed to server fr
gavin.king Feb 11, 2007 10:01 PM (in response to kevin.genie)I have not reported this, so you should go and report it.
-
13. Re: Diff in behaviour with STATE_SAVING changed to server fr
raghinii Feb 16, 2007 6:56 PM (in response to kevin.genie)heh, i didn't mean "you, Gavin, " but rather "you, Kevin", the original poster who had said he'd file it.
i don't know what happened to that, but THIS issue in the mysapces JIRA i think covers it.
http://issues.apache.org/jira/browse/MYFACES-1523