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 jus
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 uninitiated
> 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().
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
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 P
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 b
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 Inte
> 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
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 regenera
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
> 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 pag
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 n
12 matches
Mail list logo
