an idea: wicket-resilient mode?

[Korbinian Bachl <ko...@whiskyworld.de>]

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

Re: an idea: wicket-resilient mode?

[Martin Terra <ma...@koodaripalvelut.com>]

ti 11. lokak. 2022 klo 10.20 Martin Terra (martin.terra@koodaripalvelut.com)
kirjoitti:

>
>
> ti 11. lokak. 2022 klo 10.15 Korbinian Bachl (
> korbinian.bachl@whiskyworld.de) kirjoitti:
>
>> Hello Martin,
>>
>> thanks for the advise and I looked at it, however, I am not sure how to
>> solve my original idea here.
>>
>> I can swallow any error thats RuntimeException in onException in
>> IRequestCycleListener, but this leads not to the rest of the page magically
>> working, does it?
>>
>> I mean I can add a new RequestCycleListener with
>>
>> @Override
>>     public IRequestHandler onException(RequestCycle cycle, Exception ex) {
>> ..
>>
>> if(ex instanceof RuntimeException) {
>>     //swallow it
>>     return null;
>> }
>>
>>
>> in it. But as soon as we got a e.g.:
>>
>> throw new RuntimeException("test");
>>
>> anywhere in the constructor/onInit of any component the error is again
>> 500, with
>> ERROR [org.apache.wicket.DefaultExceptionMapper] Unexpected error occurred
>> java.lang.RuntimeException: test
>> [...]
>>
>> behind it.
>>
>> My idea is that the component - and only that single component - that
>> fails gets "blanked" out as it is not existing while the rest of the page
>> would work regular.
>
>
> It is your application so you must know/design how to recover from the
> error. You either re-render the same page or redirect the user to a
> suitable error page.
>

Ofcourse your first course of action should be to fix the root cause of
your exception, and only for unexpected situations, you build logic to
handle the exception.

**
Martin

>
> **
> Martin
>
>>
>>
>>
>> Or did I missunderstand anything here?
>>
>> Best,
>>
>> KB
>>
>>
>>
>>
>> ----- Ursprüngliche Mail -----
>> > Von: "Martin Terra"
>> > An: "dev" <de...@wicket.apache.org>
>> > Gesendet: Montag, 10. Oktober 2022 10:03:34
>> > Betreff: Re: an idea: wicket-resilient mode?
>>
>> > 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.terra@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.bachl@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
>> >>>
>> >>>
>> >>>
>>
>

Re: an idea: wicket-resilient mode?

[Martin Terra <ma...@koodaripalvelut.com>]

ti 11. lokak. 2022 klo 12.23 Korbinian Bachl (korbinian.bachl@whiskyworld.de)
kirjoitti:

>
>
> ----- Ursprüngliche Mail -----
> >
> > If you are ok with a 80% failing page, I cannot help you, because in that
> > case you can simply come up with another fallback which works 80%. You
> know
> > this leads/creeps to exponential growth of failures and work, yes?
> >
> > The right way to handle it is to inform the user that something has
> failed,
> > suggest the user to retry (or you can retry once programmatically if you
> > think the problem is rare).
> >
> > And receive alerts from such problems in production and find the root
> cause
> > and fix it, for example by fixing a race condition issue by adding
> blocking
> > queues or whatever best suits your use case.
>
> Well, for me the thing is: if the whole page fails you need to fix it asap
> - if only 10% of the page fails you could ignore it some time and have it
> fixed at a later point in time when you have resources
> free.
>
> I see this as a pure business administration problem: save money if
> possible... I know this is not something a programmer likes but nobody of
> us programms for free :)
>

It's same cost at the moment to program correctly as to program crap, but
if you program crap, the costs accumulate in the future, from customer
experience, trustworthiness, goodwill, support costs, rewriting the whole
application after it has become spaghetti from technical debt, and so on.
If you do not know all this, you will learn.

If it is ok to have this error then maybe just ignore it, I just hope it's
not a banking application ;)


> >
> > And from my experience I never expect my code to not have bugs in it, so
> it
> >> will fail at some point. I mean, why do we have so many regular wicket
> >> releases if its bug free? ;)
> >>
> >
> > Is not about being bug free, but how to respond to bugs and how to curb
> > bugs and how to curb the impact of bugs.
>
> Right: have a way to ignore it a maximum amount of time till you fix it...
> based on the impact of the bug itself.
> In case the bug takes down everything you need to fix it asap. If it takes
> down only a part: depending on the part itself you react...
>

Yes. Pick your battles, apply pareto principle, and so forth.

Anyways, only you can find the solution (and timing) that best fits your
application, as you know the business case and use case.

**
Martin

Re: an idea: wicket-resilient mode?

[Korbinian Bachl <ko...@whiskyworld.de>]

----- Ursprüngliche Mail -----
> 
> If you are ok with a 80% failing page, I cannot help you, because in that
> case you can simply come up with another fallback which works 80%. You know
> this leads/creeps to exponential growth of failures and work, yes?
> 
> The right way to handle it is to inform the user that something has failed,
> suggest the user to retry (or you can retry once programmatically if you
> think the problem is rare).
> 
> And receive alerts from such problems in production and find the root cause
> and fix it, for example by fixing a race condition issue by adding blocking
> queues or whatever best suits your use case.

Well, for me the thing is: if the whole page fails you need to fix it asap - if only 10% of the page fails you could ignore it some time and have it fixed at a later point in time when you have resources
free. 

I see this as a pure business administration problem: save money if possible... I know this is not something a programmer likes but nobody of us programms for free :)


> 
> And from my experience I never expect my code to not have bugs in it, so it
>> will fail at some point. I mean, why do we have so many regular wicket
>> releases if its bug free? ;)
>>
> 
> Is not about being bug free, but how to respond to bugs and how to curb
> bugs and how to curb the impact of bugs.

Right: have a way to ignore it a maximum amount of time till you fix it... based on the impact of the bug itself. 
In case the bug takes down everything you need to fix it asap. If it takes down only a part: depending on the part itself you react...

Re: an idea: wicket-resilient mode?

[Martin Terra <ma...@koodaripalvelut.com>]

> I understand your point of view while not sure this is the correct
> interpretion to see a page as a "transaction". If there are forms, maybe
> you can see it that way but a page is usually a way to present information/
> data.
>
> I had some time to work with RoR lately and the way it evolved in the last
> years and also solved many problems with clever convention over
> configuration let me rethink some of my previous ways.
> Also backend frameworks like e.g. micronaut have baked in things like
> retryable or CircuitBreaker because they just *expect* it that something
> will fail anytime anyhow.
>
> In our prod app we got a 500 because of a dumb null pointer that happend
> because of a rare race condition depending on the backend... something that
> was clearly a fault initially but only with the current way to fail the
> whole page made it a problem.
>
> The idea is just to not fail a whole page but only the part of the page
> that fails - while logging in the backend so that the usage of the page is
> not 0 but maybe still 80%
>

If you are ok with a 80% failing page, I cannot help you, because in that
case you can simply come up with another fallback which works 80%. You know
this leads/creeps to exponential growth of failures and work, yes?

The right way to handle it is to inform the user that something has failed,
suggest the user to retry (or you can retry once programmatically if you
think the problem is rare).

And receive alerts from such problems in production and find the root cause
and fix it, for example by fixing a race condition issue by adding blocking
queues or whatever best suits your use case.

And from my experience I never expect my code to not have bugs in it, so it
> will fail at some point. I mean, why do we have so many regular wicket
> releases if its bug free? ;)
>

Is not about being bug free, but how to respond to bugs and how to curb
bugs and how to curb the impact of bugs.


> PS: can you elaborate how to globally alter the sub panel phases?
>

You can make your own panel which you reuse/extend everywhere and add
custom logic to it. You can also fork wicket if it is not to your liking.
You an remove the rendering exception from your copy of wicket alltogether.

**
Martin

Re: an idea: wicket-resilient mode?

[Korbinian Bachl <ko...@whiskyworld.de>]

> ti 11. lokak. 2022 klo 11.12 Korbinian Bachl (korbinian.bachl@whiskyworld.de)
> kirjoitti:
> 
>>
>> >
>> > It is your application so you must know/design how to recover from the
>> > error. You either re-render the same page or redirect the user to a
>> > suitable error page.
>> >
>> > **
>> > Martin
>> >
>>
>> Thats exactly the misunderstanding. If one of 100s of components fails -
>> not even necessarily "made" by myself (.g.: some null pointer down the
>> drain of a Panel) - why should the whole rest of the page fail, too?
>> Why should we redirect and not just ignore the single root cause (a "bad"
>> component/ panel) silently?
>>
>> I mean, most of errors that occur in Prod for us are because something
>> happens that was never meant to be. Be it that backend data came in that
>> violated the contract (because of update of a third party service without
>> notice / or in error) or something else that is not know in advance.
>>
>> Point is: if a page consists of 1000 Components and only 1 of it fails:
>> why has this single point of failure the need to take down the rest of the
>> page?
>>
> 
> I think you should think of it like a transaction. A well designed page is
> like a transaction. If there is a fault, it should rollback everything.
> Otherwise, you need to design very carefully which faults you want to allow
> and which ones not. A quick-and-dirty way is to add catches to the sub
> panel rendering phases so that they don't care about the faults, but you
> will run a risk that your user is not getting consistent information. This
> might be a problem or it might not be.
> 
> Also, if you have lots of these, you probably have some sort of systematic
> design flaw in your application, try to debug heuristically it and solve it.
> 
> In my experience, the only situations where exceptions are "normal" in
> wicket is when there is some kind of invalid session and parts of the page
> attempt rendering while some other parts fail to render, and the correct
> action in such case is to discard rendering and redirect to login.
> 
> But your case might be different and you need to investigate the root
> cause. Otherwise you run risk of steering your product like a lost ship on
> the vast ocean with some unexpected harm ahead.
> 
> To summarize, unexpected exceptions in wicket are not normal, you should
> not allow them.
> 
> **
> Martin


I understand your point of view while not sure this is the correct interpretion to see a page as a "transaction". If there are forms, maybe you can see it that way but a page is usually a way to present information/ data.

I had some time to work with RoR lately and the way it evolved in the last years and also solved many problems with clever convention over configuration let me rethink some of my previous ways. 
Also backend frameworks like e.g. micronaut have baked in things like retryable or CircuitBreaker because they just *expect* it that something will fail anytime anyhow.

In our prod app we got a 500 because of a dumb null pointer that happend because of a rare race condition depending on the backend... something that was clearly a fault initially but only with the current way to fail the whole page made it a problem. 

The idea is just to not fail a whole page but only the part of the page that fails - while logging in the backend so that the usage of the page is not 0 but maybe still 80%

And from my experience I never expect my code to not have bugs in it, so it will fail at some point. I mean, why do we have so many regular wicket releases if its bug free? ;)

PS: can you elaborate how to globally alter the sub panel phases?

Re: an idea: wicket-resilient mode?

[Martin Terra <ma...@koodaripalvelut.com>]

ti 11. lokak. 2022 klo 11.12 Korbinian Bachl (korbinian.bachl@whiskyworld.de)
kirjoitti:

>
> >
> > It is your application so you must know/design how to recover from the
> > error. You either re-render the same page or redirect the user to a
> > suitable error page.
> >
> > **
> > Martin
> >
>
> Thats exactly the misunderstanding. If one of 100s of components fails -
> not even necessarily "made" by myself (.g.: some null pointer down the
> drain of a Panel) - why should the whole rest of the page fail, too?
> Why should we redirect and not just ignore the single root cause (a "bad"
> component/ panel) silently?
>
> I mean, most of errors that occur in Prod for us are because something
> happens that was never meant to be. Be it that backend data came in that
> violated the contract (because of update of a third party service without
> notice / or in error) or something else that is not know in advance.
>
> Point is: if a page consists of 1000 Components and only 1 of it fails:
> why has this single point of failure the need to take down the rest of the
> page?
>

I think you should think of it like a transaction. A well designed page is
like a transaction. If there is a fault, it should rollback everything.
Otherwise, you need to design very carefully which faults you want to allow
and which ones not. A quick-and-dirty way is to add catches to the sub
panel rendering phases so that they don't care about the faults, but you
will run a risk that your user is not getting consistent information. This
might be a problem or it might not be.

Also, if you have lots of these, you probably have some sort of systematic
design flaw in your application, try to debug heuristically it and solve it.

In my experience, the only situations where exceptions are "normal" in
wicket is when there is some kind of invalid session and parts of the page
attempt rendering while some other parts fail to render, and the correct
action in such case is to discard rendering and redirect to login.

But your case might be different and you need to investigate the root
cause. Otherwise you run risk of steering your product like a lost ship on
the vast ocean with some unexpected harm ahead.

To summarize, unexpected exceptions in wicket are not normal, you should
not allow them.

**
Martin

Re: an idea: wicket-resilient mode?

[Korbinian Bachl <ko...@whiskyworld.de>]

 
> 
> It is your application so you must know/design how to recover from the
> error. You either re-render the same page or redirect the user to a
> suitable error page.
> 
> **
> Martin
> 

Thats exactly the misunderstanding. If one of 100s of components fails - not even necessarily "made" by myself (.g.: some null pointer down the drain of a Panel) - why should the whole rest of the page fail, too? 
Why should we redirect and not just ignore the single root cause (a "bad" component/ panel) silently?

I mean, most of errors that occur in Prod for us are because something happens that was never meant to be. Be it that backend data came in that violated the contract (because of update of a third party service without notice / or in error) or something else that is not know in advance.

Point is: if a page consists of 1000 Components and only 1 of it fails: why has this single point of failure the need to take down the rest of the page?

Re: an idea: wicket-resilient mode?

[Martin Terra <ma...@koodaripalvelut.com>]

ti 11. lokak. 2022 klo 10.15 Korbinian Bachl (korbinian.bachl@whiskyworld.de)
kirjoitti:

> Hello Martin,
>
> thanks for the advise and I looked at it, however, I am not sure how to
> solve my original idea here.
>
> I can swallow any error thats RuntimeException in onException in
> IRequestCycleListener, but this leads not to the rest of the page magically
> working, does it?
>
> I mean I can add a new RequestCycleListener with
>
> @Override
>     public IRequestHandler onException(RequestCycle cycle, Exception ex) {
> ..
>
> if(ex instanceof RuntimeException) {
>     //swallow it
>     return null;
> }
>
>
> in it. But as soon as we got a e.g.:
>
> throw new RuntimeException("test");
>
> anywhere in the constructor/onInit of any component the error is again
> 500, with
> ERROR [org.apache.wicket.DefaultExceptionMapper] Unexpected error occurred
> java.lang.RuntimeException: test
> [...]
>
> behind it.
>
> My idea is that the component - and only that single component - that
> fails gets "blanked" out as it is not existing while the rest of the page
> would work regular.


It is your application so you must know/design how to recover from the
error. You either re-render the same page or redirect the user to a
suitable error page.

**
Martin

>
>
>
> Or did I missunderstand anything here?
>
> Best,
>
> KB
>
>
>
>
> ----- Ursprüngliche Mail -----
> > Von: "Martin Terra"
> > An: "dev" <de...@wicket.apache.org>
> > Gesendet: Montag, 10. Oktober 2022 10:03:34
> > Betreff: Re: an idea: wicket-resilient mode?
>
> > 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.terra@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.bachl@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
> >>>
> >>>
> >>>
>

Re: an idea: wicket-resilient mode?

[Korbinian Bachl <ko...@whiskyworld.de>]

Hello Martin,

thanks for the advise and I looked at it, however, I am not sure how to solve my original idea here.

I can swallow any error thats RuntimeException in onException in IRequestCycleListener, but this leads not to the rest of the page magically working, does it?

I mean I can add a new RequestCycleListener with 

@Override
    public IRequestHandler onException(RequestCycle cycle, Exception ex) {
..

if(ex instanceof RuntimeException) {
    //swallow it
    return null;    
}


in it. But as soon as we got a e.g.: 

throw new RuntimeException("test");

anywhere in the constructor/onInit of any component the error is again 500, with
ERROR [org.apache.wicket.DefaultExceptionMapper] Unexpected error occurred
java.lang.RuntimeException: test 
[...]

behind it.

My idea is that the component - and only that single component - that fails gets "blanked" out as it is not existing while the rest of the page would work regular. 


Or did I missunderstand anything here?

Best,

KB




----- Ursprüngliche Mail -----
> Von: "Martin Terra" 
> An: "dev" <de...@wicket.apache.org>
> Gesendet: Montag, 10. Oktober 2022 10:03:34
> Betreff: Re: an idea: wicket-resilient mode?

> 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.terra@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.bachl@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
>>>
>>>
>>>

Re: an idea: wicket-resilient mode?

[Martin Terra <ma...@koodaripalvelut.com>]

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.terra@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.bachl@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
>>
>>
>>
>>

Re: an idea: wicket-resilient mode?

[Martin Terra <ma...@koodaripalvelut.com>]

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.bachl@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
>
>
>
>