The improvement made by Sven has been introduced earlier with 7beaa9f and later reverted because of https://issues.apache.org/jira/browse/WICKET-4500 (7a86fe3) I.e. WICKET-4500 should be valid again. @Chris Colman: Please retest it. On Mon, Dec 24, 2012 at 2:09 AM, Chris Colman
Sorry, I wasn't aware of this back and forth. It's not clear to me how 7a86fe3 'fixed' WICKET-4500 though: If there's no session, how does it help to create one and then looking for non-present meta data? Sven On 12/27/2012 09:55 AM, Martin Grigorov wrote: The improvement made by Sven has
I don't remember the details now. Chris confirmed privately that he will re-test his scenario. I'll be able to take a look at this soon. On Thu, Dec 27, 2012 at 12:50 PM, Sven Meier s...@meiers.net wrote: Sorry, I wasn't aware of this back and forth. It's not clear to me how 7a86fe3 'fixed'
I don't remember quite well how it used to work with 1.5, but looking at your stacktrace I see you used some kind of redirection policy that involves class RestartResponseAtInterceptPageException. This class needs to build a permanent session as you can see in its method InterceptData.set:
Hi Chris, as already written, these are temporary sessions that should do no harm. Nevertheless I've added a check into RestartResponseAtInterceptPageException#InterceptData (which probes every request to be able to restore post parameters from before an intercept page) whether a session
I don't remember quite well how it used to work with 1.5, but looking at your stacktrace I see you used some kind of redirection policy that involves class RestartResponseAtInterceptPageException. I had the same reaction when I first saw the redirect but I can assure you that we're not doing any
Ah excellent! Thanks Sven. I was thinking about the creation of a simple test to be added to the test suite that would override WebApplication#newSession and then make a request for a static resource and then throw an exception if newSession gets called. This would help trap any future regression