I am sorry to report that we see the same problem. We run a page in IE, enter some values, ajax-submit, open the same page in Firefox, and the values are already there.
Does the serialization ignore the user session? We store values in CompoundPropertyModel. As for the other posters, this is critical for us. We are using the april 6 snapshot from http://wicketstuff.org/maven/repository/org/apache/wicket/wicket/1.3-SNAPSHOT/ We need that snapshot because it has the StreamCorrupted fix. We can't use 1.3.3 final because it doesn't have that fix. Please advise. Wolfgang Gehner Niels Bo wrote: > > Yes, I can do that. > > It is both Application and Session at the same time. > RequestCycle I have never seen it happen for. > > Niels > > > Johan Compagner wrote: >> >> could you change that method that it checks this after the fact? >> and then see if there is an error for that thread before? for example >> also >> log the url call so that we can see >> what kind of request did let one thread local be there? >> >> Which one is it by the way? >> is it app, session or request cycle? >> >> i just checked our code and we have finally blocks pretty much every >> where >> in WicketFilter.doGet >> and in RequestCycle.steps >> >> And i have no idea how those can be jumped over. >> >> johan >> >> >> On Wed, Apr 9, 2008 at 12:22 PM, Niels Bo <[EMAIL PROTECTED]> >> wrote: >> >>> >>> We have kind of the same problem. >>> It looks like Application and Session are not always cleared from the >>> request thread, and to test this I have just deployed a subclassed >>> WicketServlet with these checks (and also as a workaround): >>> >>> protected void service(HttpServletRequest req, HttpServletResponse >>> resp) >>> throws ServletException, IOException { >>> if(Application.exists()) { >>> LogHelper.applicationLog(ILogEvents.LOGEVENT_UNEXPECTED, >>> "Application on Thread"); >>> Application.unset(); >>> } >>> if(Session.exists()) { >>> LogHelper.applicationLog(ILogEvents.LOGEVENT_UNEXPECTED, >>> "Session on Thread"); >>> Session.unset(); >>> } >>> if(RequestCycle.get() != null) { >>> LogHelper.applicationLog(ILogEvents.LOGEVENT_UNEXPECTED, >>> "RequestCycle on Thread"); >>> RequestCycle.get().detach(); >>> } >>> >>> super.service(req, resp); // call WicketServlet >>> } >>> >>> Our logs show that it actually happens that both Application and Session >>> are >>> already attached to the thread before the request is processed. >>> I have only seen it once or twice in our development environment, but it >>> happens a few times every hour on the production server. >>> >>> Niels >>> -- >>> View this message in context: >>> http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16583880.html >>> Sent from the Wicket - User mailing list archive at Nabble.com. >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/Invoulentary-session-sharing-leakage-in-Wicket-1.3.x-tp16550360p16585349.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
