It has evolved a bit: https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+1.5#MigrationtoWicket1.5-RequestCycle
** Martin ma 10. lokak. 2022 klo 10.11 Martin Terra (martin.te...@koodaripalvelut.com) kirjoitti: > Yes. You can override runtime handling yourself @ > RequestCycle.onRuntimeException (at least used to be with such name) > > In production it is recommended to do so as you best see fit. > > ** > Martin > > ma 10. lokak. 2022 klo 9.45 Korbinian Bachl ( > korbinian.ba...@whiskyworld.de) kirjoitti: > >> Hi, >> >> we use wicket for many years now and so far it is a great framework to >> use. One thing that however seems still a bit of a problem is the way >> wicket handles (runtime) errors. >> If you look at a page then the content is often composed of 100's of >> panels and components. >> As long as every single component is working all is fine... but if just 1 >> of the many 100 components has any kind of runtime-errors it leads to a 500 >> server error. >> So I wondered: what stops us from letting wicket have a "resilient mode"? >> - A mode where an runtime error in any component doesnt lead to the error >> beeing done as a 500 but instead only let this single component/panel >> silently fail (by not outputting it - as if it would be .visible(false)) >> and do this gracefully in the background? >> While wicket doing error-logging in the background? >> All beeing done by having a setting to let wicket be gracefully/resilient >> in deploymode? >> >> What do you think about this approach? >> >> Best, >> >> Korbinian >> >> >> >>
