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
