Hi Achim, I am already using pax-web 2.0.0-SNAPSHOT with Jetty 8 and this post describes the same problem for Jetty 6:
http://jetty.4.n6.nabble.com/incorrect-session-invalidation-td35263.html I opened the Jira issue PAXWEB-358. I will try to create a workaround and contact the Jetty guys. Regards, Marc Am 28.03.2012 09:16, schrieb Achim Nierbeck: > Hi Marc, > > sorry that it took me so long to answer :( > > unfortunately I did have the issue yet, and it's especially bad to see > that it might be related to Jetty. > Is it bound to a specific Jetty version, maybe it's already fixed at > Jetty in a newer version. > Did you also try with the latest Snapshot of Pax-Web and Jetty 8? > > Still I think it's worth opening a Jira issue to track this. > > Regards, Achim > > 2012/3/17 Marc Klinger <mklin...@nightlabs.de>: >> Hi, >> >> I experience problems with Jetty sessions expiring too early. I do >> cross-context-dispatching. Every context gets an own session object from >> Jetty but is sharing the same session id (JSESSIONID cookie). Then, when >> the first session object times out, all session objects using the same >> session id are invalidated.Hi >> >> That means for my application: I start using application part A (which >> dispatches to context A). After that I use application part B (which >> dispatches to context B). While I am using the application all the time, >> the session of context A will time out (after 5 minutes by default) and >> also invalidate all other sessions (including B). >> >> This behaviour also applies in a "normal" Jetty environment with a root >> application (context path "/") and another application (e.g. context >> path "/foobar"). Both applications use the same session id but different >> session objects. The session that times out first will destroy all other >> sessions. Tomcat seems to handle this situation differently. >> >> In the case of Pax Web, it looks like this also applies without doing >> cross-context dispatching. When I deploy Felix web console it also >> shares the session id with other web contexts. >> >> Has anyone here also experienced this problem and maybe knows a >> workaround? I extended HashSessionManager with a hack that should avoid >> this problem, but I have no idea how I could tell Jetty or Pax Web to >> use my implementation instead of the default HashSessionManager. I'd >> like to avoid patching Jetty. Any ideas? >> >> Regards, >> Marc >> >> _______________________________________________ >> general mailing list >> general@lists.ops4j.org >> http://lists.ops4j.org/mailman/listinfo/general > > > _______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general