That's a rather peculiar requirement. Sessions are semi-managed by the container and I don't know of a container that would allow you to do that. If you used Shiro in native session mode, you could probably change the id but even then, you'd need to cast and use the implementation classes directly.
Kalle On Tue, Oct 19, 2010 at 2:40 PM, Mike Oestereter <mike.oestere...@gmail.com> wrote: > The problem is that I don't want to invalidate the session from an > application point of view. > > After successful login I want to store details about the authenticated > user in the user session. > > I just want to kill the existing cookie and associate a new (and > different cookie) with the current session. > > > On Mon, Oct 18, 2010 at 3:13 PM, Thiago H. de Paula Figueiredo > <thiag...@gmail.com> wrote: >>> Grabbing the session and invalidating directly does the trick but >>> you have to be sure this occurs at the end of the request - otherwise >>> Tapestry may try to reuse the session and because that has been >>> invalidated you'd get exceptions. >> >> As long as you invalidate it through Tapestry (Session.invalidate()) instead >> of directly through HttpSession.invalidate(), I don't think exceptions will >> be thrown. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
