Thanks Eelco, that did the trick.
Couple of follow up questions/comments that anyone can field:
1) I understand why you would want a stateless application, however I don't
understand why you would ever want your session to be regenerated on each
request if during the request you specifically set
On 7/24/07, spencer.c [EMAIL PROTECTED] wrote:
Thanks Eelco, that did the trick.
Couple of follow up questions/comments that anyone can field:
1) I understand why you would want a stateless application, however I
don't
understand why you would ever want your session to be regenerated on
Couple of follow up questions/comments that anyone can field:
1) I understand why you would want a stateless application, however I don't
understand why you would ever want your session to be regenerated on each
request if during the request you specifically set a session value. It
seems
Alright, so from what you guys have said, I think there is a bug.
I had not called session.dirty() before, but since that sounded reasonable,
I took out the call to session.bind() and updated my property setter so that
after it set the value, it called dirty. In this simple case:
public
On 7/24/07, spencer.c [EMAIL PROTECTED] wrote:
Alright, so from what you guys have said, I think there is a bug.
Darn! :) Could you open an issue please? I'll look into it asap.
Eelco
-
This SF.net email is sponsored by:
You need to call session.bind().
We've been discussing this many times. It's no good to make
session.dirty() bind the session, because it's called internally even
on sessions that should not be bound.
-Matej
On 7/24/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 7/24/07, spencer.c [EMAIL
On 7/24/07, spencer.c [EMAIL PROTECTED] wrote:
Thanks Eelco, that did the trick.
Couple of follow up questions/comments that anyone can field:
1) I understand why you would want a stateless application, however I don't
understand why you would ever want your session to be regenerated on each
You need to call session.bind().
We've been discussing this many times. It's no good to make
session.dirty() bind the session, because it's called internally even
on sessions that should not be bound.
On 7/24/07, Matej Knopp [EMAIL PROTECTED] wrote:
You need to call session.bind().
Sorry Matej, I opened the bug per Eelco's request before receiving your two
responses.
I will close the issue, since it sounds like this has been discussed before,
and there are technical reasons for it staying as is. I guess this is just
a confirmation that it not intuitive to the
On 7/24/07, spencer.c [EMAIL PROTECTED] wrote:
Sorry Matej, I opened the bug per Eelco's request before receiving your two
responses.
I will close the issue, since it sounds like this has been discussed before,
and there are technical reasons for it staying as is. I guess this is just
a
I have a custom session class that inherits from WebSession. I have
overridden the newSession method in my Application class. The session is
getting used during the request, because I initialize some of its values in
its constructor, and they show up when I attach a label to them in a page.
A
I have a custom session class that inherits from WebSession. I have
overridden the newSession method in my Application class. The session is
getting used during the request, because I initialize some of its values in
its constructor, and they show up when I attach a label to them in a page.
12 matches
Mail list logo
