Hi Marc, that'll be cool if you could take care of this :)
Thanx, Achim 2012/3/29 Marc Klinger <mklin...@nightlabs.de>: > 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 -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead blog <http://notizblog.nierbeck.de/> _______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
