because we don't make a session in the doGet that only happens a few steps later when we really need
to store a page in the session.
Do you use filters? that do request.getSession(true) ?
Maybe we should listen to session destructions on some place and really clear the map
I now just made a commit that when you do invalidate through wicket the buffered map will be cleared.
So now only the time out sessions can have a buffer but that is not very likely because they aren't in a redirect.
johan
On 3/2/06, jan_bar
<[EMAIL PROTECTED]> wrote:
Thanks Johan,
(I cannot indent your message, because it is not plain text). I have exactly
the situation you describe. I use the REDIREC_TO_BUFFER, invalidate a page a
no redirect. With Jetty I get "session expired" page, which is expected, but
with Tomcat I get back the original page. Only after subsequent refresh or
button click I get the "session expired". This is due to the fact, that the
buffered response was not cleared from the map.
Jan
"Johan Compagner" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
that map doesn't really matter
it is only filled with something if we send out a client side redirect to a
page that we already renderd (REDIREC_TO_BUFFER)
So it will only go "wrong" if the session got invalidated in a request then
a redirect is done to a page that was created for that request
But i guess this is maybe even wat you want because maybe it is the ByeBye
page?
The problem is that a buffered response isn't even checked for a new session
(or better said not yet created session)
because we don't create the session at that time..
We could stored those redirect buffers in the session, but we don't want
that because the session could be clusted ect and then it is constanlty
touched and updated and therefor replicated.
johan
On 3/2/06, jan_bar <[EMAIL PROTECTED]> wrote:
Hi,
I created a little application that tests various session behaviour. I
notied something interesting with Tomcat. When session is invalidated and
browser sends request to Tomcat with session id in cookie (the session was
invalidated), Tomcat doesn't create new session with new id, it just reuse
the session id. Just to be clean about that, here is part of the log:
PersistentSessionListener.sessionCreated(), id =
94B93B22C9E1B8B2EFA96807764C12E9
PersistentSessionListener.sessionDestroyed(), id =
94B93B22C9E1B8B2EFA96807764C12E9
PersistentSessionListener.sessionCreated(), id =
94B93B22C9E1B8B2EFA96807764C12E9
Even if suprising behaviour, it is in my opinion correct. Why to generate
new session id when I can reuse the already generated one?
And now to the point. It seems to me that Wicket 1.1.1 is not prepared to
handle this correctly, for instance the WebApplication.redirectMap contains
entries, that are not valid for the new session if it has the same id.
Can someone confirm this?
I use JBoss 4.0.3SP1
Thanks, Jan
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
