Re: Cannot get to desired error page on handling RuntimeException in AbstractRequestCycleListener#onException()
Thanks Martin. Good to know about the other option. I'll go with Session.get().bind(); since I get the redirect to the error page. Otherwise, if I add the RedirectPolicy.NEVER_REDIRECT to the RenderPageRequestHandler there will still be the original value in the URL bar of the browser. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Cannot-get-to-desired-error-page-on-handling-RuntimeException-in-AbstractRequestCycleListener-onExce-tp4662078p4662170.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: Cannot get to desired error page on handling RuntimeException in AbstractRequestCycleListener#onException()
On Tue, Nov 5, 2013 at 10:46 PM, dgn wrote: > Here's what I've come up with. > > My error page, CustomErrorPage.java, has 3 constructors: > 1) no-arg > 2) CustomErrorPage(PageParameters pp) > 3) CustomErrorPage(Exception e) > > Once I added Session.get().bind() immediately before returning the custom > error page instance I get the desired page dispatching. This works with all > three constructors, including the one with the Exception parameter so I now > have access to, and can display, information related to the exception. > > Thanks for the suggestion You were running stateless and the error page was not saved for the redirect. Another solution is to use: new RenderPageRequestHandler(pageProvider, RedirectPolicy.NEVER_REDIRECT) > . > > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Cannot-get-to-desired-error-page-on-handling-RuntimeException-in-AbstractRequestCycleListener-onExce-tp4662078p4662149.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: Cannot get to desired error page on handling RuntimeException in AbstractRequestCycleListener#onException()
Here's what I've come up with. My error page, CustomErrorPage.java, has 3 constructors: 1) no-arg 2) CustomErrorPage(PageParameters pp) 3) CustomErrorPage(Exception e) Once I added Session.get().bind() immediately before returning the custom error page instance I get the desired page dispatching. This works with all three constructors, including the one with the Exception parameter so I now have access to, and can display, information related to the exception. Thanks for the suggestion. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Cannot-get-to-desired-error-page-on-handling-RuntimeException-in-AbstractRequestCycleListener-onExce-tp4662078p4662149.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: Cannot get to desired error page on handling RuntimeException in AbstractRequestCycleListener#onException()
On Tue, Nov 5, 2013 at 8:27 PM, dgn wrote: > Ah, now I read more closely. My apologies... > > Yes, using new PageProvider(new CustomErrorPage.class) results in the > desired behavior where AbstractRequestCycleListener#onException() is only > called once. > > I'm curious why using an explicit constructor of a class as a parameter of > "new PageProvider()" causes multiple calls to onException() where the later > calls contain a PageExpiredException. > > Ideally I'd like to be able to capture any message contained within the > original exception that was being trapped and passing it to the > CustomErrorPage. Is there another means of capturing this exception? > > Try with: Session.get().bind() before returning the error page *instance*. > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Cannot-get-to-desired-error-page-on-handling-RuntimeException-in-AbstractRequestCycleListener-onExce-tp4662078p4662145.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: Cannot get to desired error page on handling RuntimeException in AbstractRequestCycleListener#onException()
I'm curious why using an explicit constructor of a class as a parameter of "new PageProvider()" causes multiple calls to onException() We're curious too, please create a quickstart exposing this behavior. And please check with the latest Wicket 6.x version. Sven On 11/05/2013 07:27 PM, dgn wrote: Ah, now I read more closely. My apologies... Yes, using new PageProvider(new CustomErrorPage.class) results in the desired behavior where AbstractRequestCycleListener#onException() is only called once. I'm curious why using an explicit constructor of a class as a parameter of "new PageProvider()" causes multiple calls to onException() where the later calls contain a PageExpiredException. Ideally I'd like to be able to capture any message contained within the original exception that was being trapped and passing it to the CustomErrorPage. Is there another means of capturing this exception? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Cannot-get-to-desired-error-page-on-handling-RuntimeException-in-AbstractRequestCycleListener-onExce-tp4662078p4662145.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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Cannot get to desired error page on handling RuntimeException in AbstractRequestCycleListener#onException()
Ah, now I read more closely. My apologies... Yes, using new PageProvider(new CustomErrorPage.class) results in the desired behavior where AbstractRequestCycleListener#onException() is only called once. I'm curious why using an explicit constructor of a class as a parameter of "new PageProvider()" causes multiple calls to onException() where the later calls contain a PageExpiredException. Ideally I'd like to be able to capture any message contained within the original exception that was being trapped and passing it to the CustomErrorPage. Is there another means of capturing this exception? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Cannot-get-to-desired-error-page-on-handling-RuntimeException-in-AbstractRequestCycleListener-onExce-tp4662078p4662145.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: Cannot get to desired error page on handling RuntimeException in AbstractRequestCycleListener#onException()
Hi, On Mon, Nov 4, 2013 at 4:00 PM, dgn wrote: > I'm using Wicket 6. > > As you can see I'm already using new PageProvider(new CustomErrorPage()) > Sven suggested you to try with the other constructor of PageProvider - the one that access a Class. > when I get the runtime exception I'm targeting. > > What I'm wondering and perhaps don't understand fully is the Wicket request > lifecycle. What is causing the callback to onException() multiple times? > The > first time I'm unwrapping the desired exception but subsequently it's a > PageExpiredException. I'm pretty sure my CustomErrorPage is stateless so > don't understand why the additional exceptions. Any suggestions? > If you are able to reproduce the problem in a mini application then create a ticket in JIRA and attach it. We will take a look what goes wrong. > > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Cannot-get-to-desired-error-page-on-handling-RuntimeException-in-AbstractRequestCycleListener-onExce-tp4662078p4662109.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: Cannot get to desired error page on handling RuntimeException in AbstractRequestCycleListener#onException()
I'm using Wicket 6. As you can see I'm already using new PageProvider(new CustomErrorPage()) when I get the runtime exception I'm targeting. What I'm wondering and perhaps don't understand fully is the Wicket request lifecycle. What is causing the callback to onException() multiple times? The first time I'm unwrapping the desired exception but subsequently it's a PageExpiredException. I'm pretty sure my CustomErrorPage is stateless so don't understand why the additional exceptions. Any suggestions? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Cannot-get-to-desired-error-page-on-handling-RuntimeException-in-AbstractRequestCycleListener-onExce-tp4662078p4662109.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: Cannot get to desired error page on handling RuntimeException in AbstractRequestCycleListener#onException()
Which Wicket version? Try out: new PageProvider(CustomErrorPage.class) Regards Sven On 11/01/2013 08:42 PM, dgn wrote: I have a page in which an entity's ID is passed as a parameter. During the page construction a check is done on the backing database for the entity's existence. If it doesn't exist a custom RepositoryProviderException is thrown (which extends RuntimeException). I have extended AbstractRequestCycleListener and added it to RequestCycleListenerCollection in Application.init() In the onException() method there is a check for the custom exception with a dispatch to a custom error page, otherwise the standard error page: public IRequestHandler onException(RequestCycle cycle, Exception e) { RepositoryProviderException rpe = Exceptions.findCause( e, RepositoryProviderException.class ); if (rpe != null) { return new RenderPageRequestHandler(new PageProvider(new CustomErrorPage())); } return new RenderPageRequestHandler(new PageProvider(new ErrorPage())); } In testing when a RepositoryProviderException is thrown this method is invoked multiple times. The first time creates the new CustomErrorPage followed by two subsequent calls where the Exception parameter is always an ExpiredPageException. There is the following logging after the second two entries into this method: 2013-11-01 15:26:50,008 WARN RequestCycleExtra:342 - 2013-11-01 15:26:50,009 WARN RequestCycleExtra:343 - Handling the following exception org.apache.wicket.protocol.http.PageExpiredException: Page with id '1' has expired. 2013-11-01 15:26:50,009 WARN RequestCycleExtra:344 - 2013-11-01 15:26:50,018 WARN RequestCycleExtra:342 - 2013-11-01 15:26:50,018 WARN RequestCycleExtra:343 - Handling the following exception org.apache.wicket.protocol.http.PageExpiredException: Page with id '0' has expired. 2013-11-01 15:26:50,018 WARN RequestCycleExtra:344 - Why the extra calls and not the dispatch to CustomErrorPage, which is stateless and isErrorPage() returns true; ??? Thanks in advance. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Cannot-get-to-desired-error-page-on-handling-RuntimeException-in-AbstractRequestCycleListener-onExce-tp4662078.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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Cannot get to desired error page on handling RuntimeException in AbstractRequestCycleListener#onException()
I have a page in which an entity's ID is passed as a parameter. During the page construction a check is done on the backing database for the entity's existence. If it doesn't exist a custom RepositoryProviderException is thrown (which extends RuntimeException). I have extended AbstractRequestCycleListener and added it to RequestCycleListenerCollection in Application.init() In the onException() method there is a check for the custom exception with a dispatch to a custom error page, otherwise the standard error page: public IRequestHandler onException(RequestCycle cycle, Exception e) { RepositoryProviderException rpe = Exceptions.findCause( e, RepositoryProviderException.class ); if (rpe != null) { return new RenderPageRequestHandler(new PageProvider(new CustomErrorPage())); } return new RenderPageRequestHandler(new PageProvider(new ErrorPage())); } In testing when a RepositoryProviderException is thrown this method is invoked multiple times. The first time creates the new CustomErrorPage followed by two subsequent calls where the Exception parameter is always an ExpiredPageException. There is the following logging after the second two entries into this method: 2013-11-01 15:26:50,008 WARN RequestCycleExtra:342 - 2013-11-01 15:26:50,009 WARN RequestCycleExtra:343 - Handling the following exception org.apache.wicket.protocol.http.PageExpiredException: Page with id '1' has expired. 2013-11-01 15:26:50,009 WARN RequestCycleExtra:344 - 2013-11-01 15:26:50,018 WARN RequestCycleExtra:342 - 2013-11-01 15:26:50,018 WARN RequestCycleExtra:343 - Handling the following exception org.apache.wicket.protocol.http.PageExpiredException: Page with id '0' has expired. 2013-11-01 15:26:50,018 WARN RequestCycleExtra:344 - Why the extra calls and not the dispatch to CustomErrorPage, which is stateless and isErrorPage() returns true; ??? Thanks in advance. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Cannot-get-to-desired-error-page-on-handling-RuntimeException-in-AbstractRequestCycleListener-onExce-tp4662078.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