Re: Handling ReplaceHandlerException on continueToOriginalDestination in wicket 1.5
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 RedirectRequestHandler) if the original request was for some bookmarkable page. The exception eventually will get intercepted in the request handler code and the new request handler will get executed, and the requested page will eventually be rendered. Since before WICKET-4269 addressed the return values of continueToOriginalDestination(), that method return values were used to determine whether a redirect to the default (usually home page) or a redirect to the requested page is to take place. I was catching an Exception in the login page which also intercepted the ReplaceHandlerException which prevented the replacement request handler from being successfully executed down the road. I didn't realize this until I attached a debugger to the authentication examples. Developers can correct me if I'm off in my explanation here. -Martin- -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Handling-ReplaceHandlerException-on-continueToOriginalDestination-in-wicket-1-5-tp4101981p4123670.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Handling ReplaceHandlerException on continueToOriginalDestination in wicket 1.5
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 something that can be done to prevent an exception and receive a boolean response from the call, or if the exception is expected (which makes the boolean logic irrelevant), how to handle it most appropriately so the next request handler is executed (which is what replaceAllRequestHandlers() is intended to perform in the first place)? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Handling-ReplaceHandlerException-on-continueToOriginalDestination-in-wicket-1-5-tp4101981p4115437.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Handling ReplaceHandlerException on continueToOriginalDestination in wicket 1.5
In MyAuthorizationStrategy that implements IAuthorizationStrategy I throw
RestartResponseAtInterceptPageException( LoginPage.class ) if the user is
not logged in and requests a bookmarkable page.
In the LoginPage onSubmit() the call is made:
if ( !continueToOriginalDestination() )
{
setResponsePage( getApplication().getHomePage() );
}
return;
The call to continueToOriginalDestination always throws
ReplaceHandlerException and never gets to the 'return' part because it seems
that there is still an active RequestHandler in the RequestHandlerStack.
Do I need to explicitly handle this exception and detach() the current
RequestHandler to let the next scheduled handler execute (and redirect to
the bookmarkable page request), or do I prevent the exception from occuring
somehow (since there wasn't one thrown in wicket 1.4.x)?
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Handling-ReplaceHandlerException-on-continueToOriginalDestination-in-wicket-1-5-tp4101981p4101981.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
