I fixed my problem, although it's not very elegant.
I derived my own servlet from ApplicationServlet and overwrote doGet &
doPost. Then, before I called super() on each, I checked for the
cookie using raw Servlet API and deleted it (without the traling
slash) the old fashioned way. All is nice and dandy now :-)
I do thing CookieSourceImpl should be enhanced.
@Override
public void doGet(HttpServletRequest aRequest, HttpServletResponse
aResponse)
throws IOException, ServletException {
HttpSession session = aRequest.getSession(false);
if(readCookieValue(aRequest,"JSESSIONID") != null && session ==
null) {
deleteJSessionId(aRequest, aResponse);
}
super.doGet(aRequest, aResponse);
}
public String readCookieValue(HttpServletRequest aRequest, String
aName) {
Cookie[] cookies = aRequest.getCookies();
if (cookies == null)
return null;
for (int i = 0; i < cookies.length; i++) {
if (cookies[i].getName().equals(aName))
return cookies[i].getValue();
}
return null;
}
public void deleteJSessionId(HttpServletRequest aRequest,
HttpServletResponse aResponse) {
Cookie cookie = new Cookie("JSESSIONID", null);
cookie.setPath(aRequest.getContextPath());
cookie.setMaxAge(0);
aResponse.addCookie(cookie);
}
Adam
On 3/21/06, Adam Zimowski <[EMAIL PROTECTED]> wrote:
> 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]
