> 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().
>
> 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.
You are right. But we do have a problem here. Maybe we should revisit
this code and specify what the dirty bit actually should mean. If even
we devs can't agree on it, what can we expect from our users?
Originally, the idea behind dirty was to be able to detect when we
needed to flush changes to the session (i.e. set the session as an
attribute on the http session) so that a cluster could be notified.
When this bit was introduced (pre 1.1 I believe), Wicket didn't have a
stateless mode, so that wasn't a consideration back then.
The code now:
if (dirty)
{
this.dirty = false;
setAttribute(SESSION_ATTRIBUTE_NAME, this);
}
seems to be exactly that. But this doesn't make sense when the session
is not bound anyway! Also, I know there are quite a few methods
calling Session#dirty, but I wonder if they all do it for the good
reasons.
The problem with explicitly calling bind is that the session store's
bind implementation is called as well. Maybe that implementation
should do some more checking whether the session was already bound or
not.
Eelco
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
