I created a patch, see: https://issues.apache.org/jira/browse/WICKET-563
The error page creation is now delegated to Application. I think it is logical to create these page in Application, because: - Application also creates the home page. Now it can create error pages that have the same style/page layout (using borders, panels, etc.) - You always must override Application, so this makes it only a few lines of extra code to override error pages, and you don't have to extend other classes (no need to extend the IRequestCycleFactory and WebRequestCycle anymore). The exception handling is still done in AbstractRequestCycleProcessor. Exceptions are caught there, and based on the type of exception it calls: - onAuthorizationException() - onPageExpiredException() - onRuntimeException() The onRuntimeException() determines if it displays the internal error page or the exception error page. Also, if the rendering of an error page throws an exception, this is handled by AbstractRequestCycleProcessor. If the page returned by onAuthorizationException() fails to render or the page returned by onPageExpiredException() fails to render, then the onRuntimeException will be called, and if that fails, it will just throw a WicketRuntimeException that will be caught by the servlet container. This behavior was already implemented, but didn't work when the RequestCycle's onRuntimeException returns a custom page (it returned null by default). If the custom error page failed to render, the application goes into and endless loop. My patch also makes the error page settings unused. So the setPageExpiredErrorPage(Class ...) etc. methods can be removed. I hope my explanation is clear. Bart. > -----Oorspronkelijk bericht----- > Van: Johan Compagner [mailto:[EMAIL PROTECTED] > Verzonden: woensdag 9 mei 2007 14:59 > Aan: [email protected] > Onderwerp: Re: An easier way to create a custom replacement > for ExceptionErrorPage? > > yes please! > > On 5/9/07, Bart Molenkamp <[EMAIL PROTECTED]> wrote: > > > > I can see if I can create a patch for the exception handling > > part. > > > > Should I upload it to JIRA? > > > > > -----Oorspronkelijk bericht----- > > > Van: Johan Compagner [mailto:[EMAIL PROTECTED] > > > > > > Who is going to make a patch so that we can look at some code > > > instead of > > > discussing it :) > > > > > > johan > > > > > > > > > On 5/9/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > > > > > > > I think that it's fine to have the method on the > > > Application class. > > > > > You need to extend it anyway, so overriding > > > onRuntimeException is very > > > > > easy to do. And I do think it does belong there, because > > > it knows how > > > > > to create the homepage, I think it's logical that it also > > > knows how to > > > > > create an error page. > > > > > > > > For the system I'm working on, I assign a unique id to > every request > > > > cycle, which serves as an error ticked id once an exception > > > occurs. It > > > > feelts natural to assign that in the request cycle, and > I believe it > > > > feels just as natural to put the related error handling in > > > the request > > > > cycle. Application is meant for settings and factories, > and imho, a > > > > request related error call back would just be wrongly > > > scoped when put > > > > in the application class. > > > > > > > > > Do you mean you want to remove all those factory > > > interfaces for simple > > > > > factory methods on Application? > > > > > > > > That would be my ideal, yes. > > > > > > > > Eelco > > > > > > > > > >
