Hi, Martin.
"First, sorry for any mistakes, but I am Brazilian and my English is not
very good." :-)
I need your help. I found exactly the same problems you, as follows:
*
// This page will be redirect to a page intercepting
public class Checkout extends WebPage {
User loggedInUser = sessi
To follow up, and to put this issue at rest, here's the explanation (thanks
to the wicket authentication examples):
The ReplaceHandlerException will get thrown if there is an active request
handler on the stack to stop its execution and start executing the new
request handler (usually RedirectReque
https://issues.apache.org/jira/browse/WICKET-4269
-igor
On Mon, Nov 28, 2011 at 6:47 AM, peakmop wrote:
> Tor Iver is correct, in 1.4.x the call to continueToOriginalDestination
> didn't throw an exception but rather a boolean result. While in 1.5.x it
> still returns a boolean result, but it do
Tor Iver is correct, in 1.4.x the call to continueToOriginalDestination
didn't throw an exception but rather a boolean result. While in 1.5.x it
still returns a boolean result, but it does so if
replaceAllRequestHandlers() call returns without throwing an exception.
My question is twofold: is there
On Thu, Nov 24, 2011 at 10:43 AM, Wilhelmsen Tor Iver
wrote:
>> continueToOriginalDestination() does alway sthrow the replacehandler
>> exception. this is how that method works...
>
> In 1.5 perhaps, in 1.4 it returns false if it was not a redirect; that might
> be the cause of confusion.
The be
> continueToOriginalDestination() does alway sthrow the replacehandler
> exception. this is how that method works...
In 1.5 perhaps, in 1.4 it returns false if it was not a redirect; that might be
the cause of confusion.
- Tor Iver
---
dont really understand what you mean...
continueToOriginalDestination() does alway sthrow the replacehandler
exception. this is how that method works...
why is it a problem/why are you trying to deal with the new handler?
-igor
On Wed, Nov 23, 2011 at 2:57 PM, peakmop wrote:
> In MyAuthorizati
