I have found the problem, and traced it to what I see as limitation in
how CookieSource interface is implemented (see CookieSourceImpl) in
Tapestry source.

While a pretty good assumtion, CookieSourceImpl took a liberty of
appending "/" to the end of context path:

CookieSourceImpl.java :

067        public void removeCookieValue(String name)
068        {
069            Cookie cookie = new Cookie(name, null);
070            cookie.setPath(_request.getContextPath() + "/");
071            cookie.setMaxAge(0);
072
073            _response.addCookie(cookie);
074        }

and so when I'm trying to remove a JSESSIONID cookie it writes a new
one instead of deleting the one I want. This happens because Tomcat
writes JSESSIONID without the trailing slash, but CookieSourceImpl
automatically adds one.

So I'd like to implement CookieSource interface on my own. But then,
how do I tell Tapestry to use that instead?

Also, wouldn't it be better for this to be a configurable switch? Or
maybe provide sister methods for write and delete cookie value methods
which take a boolean defining if slash should be appended or not?
Default should stay as is, but the option I think is missing.

Thoughts?  Also, anybody knows how I could force my own implementation
of CookieSource?

Best Regards,
Adam

On 3/21/06, Adam Zimowski <[EMAIL PROTECTED]> wrote:
> Hello Gurus,
>
> I have a working session persistence layer in my application.
> Everything is great except one little annoyance..
>
> My app takes advantage of Tapestry's intelligent session management,
> and doesn't create one unless needed (actually Tapestry controls
> that). Once session is created and pesistence enabled, my app
> serializes attributes to the database.  When app server on the cluster
> dies, another one picks up the slack and restores the session. This is
> detected when JSESSIONID cookie value is found, but a session is null.
> The app server checks for the database, and if matching session id is
> found, restores it and the user doesn't even know what happened.
>
> Now, if the session simply expires and user chooses not to log back
> in, but continues as a "guest", I'm gonna end up with what I call a
> "stale session cookie". Currently my app takes a db hit every time
> because JSESSIONID exists, yet session is null (gone, expired).
>
> The first, and only thing I tried was to remove the cookie:
>
> if(sDbg()) _sLog.warn("stale session cookie: " + oldSessionId);
> if(!restoreSession(oldSessionId)) {
>  if(sDbg()) _sLog.debug("removing stale cookie: " + oldSessionId);
>  cookie.removeCookieValue(COOKIE_SESSION_ID);
> }
>
> But for whatever reason that does not work. It is annoying, but I
> don't seem to be able to remove that cookie value. How come?
>
> Adam
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to