Re: Component.getPage() and Exception Handling
Hey all, after few hours of debugging, clean the inheritance structure and the right call of "onBeforeRender" vs "add;addOrReplace" > it works! :) Yeah ... was hard stuff and a better code review will make something simplier. Thx for your help/motivation :) Greets Daniel Am 24.08.2020 um 17:07 schrieb Sven Meier: Hi, I didn't understand what's your problem. Sven On 24.08.20 16:56, Daniel Weiss wrote: Hello all, I don't like the exception handling of Component.getPage(). We are working on the integration to Wicket 8.4. We use panels or dialogs as anonymous classes / instances and this feature will blocked us to redefine a parent component or page. In fact (I think ..) we don't need this to handle anonymous implementations. My first thoughts about this was "what the hell ... why ... and whats the benefit of it?" :) Please explain or link a reason,documentation etc. to handle it and the reason for it. Thx in advance! Daniel https://issues.apache.org/jira/browse/WICKET-6415 https://github.com/apache/wicket/commit/140fea6/ - 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: Component.getPage() and Exception Handling
Hi, I didn't understand what's your problem. Sven On 24.08.20 16:56, Daniel Weiss wrote: Hello all, I don't like the exception handling of Component.getPage(). We are working on the integration to Wicket 8.4. We use panels or dialogs as anonymous classes / instances and this feature will blocked us to redefine a parent component or page. In fact (I think ..) we don't need this to handle anonymous implementations. My first thoughts about this was "what the hell ... why ... and whats the benefit of it?" :) Please explain or link a reason,documentation etc. to handle it and the reason for it. Thx in advance! Daniel https://issues.apache.org/jira/browse/WICKET-6415 https://github.com/apache/wicket/commit/140fea6/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Component.getPage() and Exception Handling
Hello all, I don't like the exception handling of Component.getPage(). We are working on the integration to Wicket 8.4. We use panels or dialogs as anonymous classes / instances and this feature will blocked us to redefine a parent component or page. In fact (I think ..) we don't need this to handle anonymous implementations. My first thoughts about this was "what the hell ... why ... and whats the benefit of it?" :) Please explain or link a reason,documentation etc. to handle it and the reason for it. Thx in advance! Daniel https://issues.apache.org/jira/browse/WICKET-6415 https://github.com/apache/wicket/commit/140fea6/
RE: Exception handling wicket 8
Thanks for fast response, ive created quickstart and attached it to JIRA issue
https://issues.apache.org/jira/browse/WICKET-6637
Matus
-Original Message-
From: Martin Grigorov
Sent: Monday, February 18, 2019 1:49 PM
To: users@wicket.apache.org
Subject: Re: Exception handling wicket 8
Hi,
Sounds like a bug in Wicket.
If you can reproduce it in a quickstart (mini) application then please attach
it to a ticket in JIRA!
Thanks!
On Mon, Feb 18, 2019 at 2:45 PM HOPPAN Matúš wrote:
> Hi,
>
> recently we have upgraded our application, from wicket 7.11 to wicket
> 8.3.0.
> With wicket 7 everything seemed to be fine, however in wicket 8 we
> have an issue with handling exception.
> In Application we have in init() method:
>
> getRequestCycleListeners().add(new
> MyRequestCycleListener());
>
>
>
> MyRequestCycleListener implements IRequestCycleListener and override
> method
>
>
> @Override
> public IRequestHandler onException(RequestCycle cycle, Exception ex) {}
> Optional target = cycle.find(AjaxRequestTarget.class);
> //this part stopped working since it return Optional.empty(),
> because active RequestHandler
> //and RequestHandlerScheduledAfterCurrent are both null
> if (target.isPresent()) {
> return target.get();
> }
> IPageRequestHandler last =
> PageRequestHandlerTracker.getLastHandler(RequestCycle.get());
> WebPage page = (WebPage) (last.getPage());
>return new RenderPageRequestHandler(new
> PageProvider(currentPage));
>}
>
>
> Is this a wicket bug or it was intention to work like this? If it was
> intentended, is there any workaround to get the AjaxRequestTarget? Or
> the approach has changed in wicket 8? Any other ideas?
>
>
> Matus
>
>
>
> Táto správa je určená iba pre uvedeného príjemcu a môže obsahovať
> dôverné alebo interné informácie. Ak ste ju omylom obdržali,
> upovedomte o tom prosím odosielateľa a vymažte ju. Akýkoľvek iný
> spôsob použitia tohto e-mailu je zakázaný.
>
> This message is for the designated recipient only and may contain
> confidential or internal information. If you have received it in
> error, please notify the sender immediately and delete the original.
> Any other use of the e-mail by you is prohibited.
>
Táto správa je určená iba pre uvedeného príjemcu a môže obsahovať dôverné alebo
interné informácie. Ak ste ju omylom obdržali, upovedomte o tom prosím
odosielateľa a vymažte ju. Akýkoľvek iný spôsob použitia tohto e-mailu je
zakázaný.
This message is for the designated recipient only and may contain confidential
or internal information. If you have received it in error, please notify the
sender immediately and delete the original. Any other use of the e-mail by you
is prohibited.
Re: Exception handling wicket 8
Hi,
Sounds like a bug in Wicket.
If you can reproduce it in a quickstart (mini) application then please
attach it to a ticket in JIRA!
Thanks!
On Mon, Feb 18, 2019 at 2:45 PM HOPPAN Matúš wrote:
> Hi,
>
> recently we have upgraded our application, from wicket 7.11 to wicket
> 8.3.0.
> With wicket 7 everything seemed to be fine, however in wicket 8 we have an
> issue
> with handling exception.
> In Application we have in init() method:
>
> getRequestCycleListeners().add(new
> MyRequestCycleListener());
>
>
>
> MyRequestCycleListener implements IRequestCycleListener and override method
>
>
> @Override
> public IRequestHandler onException(RequestCycle cycle, Exception ex) {}
> Optional target = cycle.find(AjaxRequestTarget.class);
> //this part stopped working since it return Optional.empty(), because
> active RequestHandler
> //and RequestHandlerScheduledAfterCurrent are both null
> if (target.isPresent()) {
> return target.get();
> }
> IPageRequestHandler last =
> PageRequestHandlerTracker.getLastHandler(RequestCycle.get());
> WebPage page = (WebPage) (last.getPage());
>return new RenderPageRequestHandler(new
> PageProvider(currentPage));
>}
>
>
> Is this a wicket bug or it was intention to work like this? If it was
> intentended, is there
> any workaround to get the AjaxRequestTarget? Or the approach has changed
> in wicket 8? Any other ideas?
>
>
> Matus
>
>
>
> Táto správa je určená iba pre uvedeného príjemcu a môže obsahovať dôverné
> alebo interné informácie. Ak ste ju omylom obdržali, upovedomte o tom
> prosím odosielateľa a vymažte ju. Akýkoľvek iný spôsob použitia tohto
> e-mailu je zakázaný.
>
> This message is for the designated recipient only and may contain
> confidential or internal information. If you have received it in error,
> please notify the sender immediately and delete the original. Any other use
> of the e-mail by you is prohibited.
>
Exception handling wicket 8
Hi,
recently we have upgraded our application, from wicket 7.11 to wicket 8.3.0.
With wicket 7 everything seemed to be fine, however in wicket 8 we have an issue
with handling exception.
In Application we have in init() method:
getRequestCycleListeners().add(new MyRequestCycleListener());
MyRequestCycleListener implements IRequestCycleListener and override method
@Override
public IRequestHandler onException(RequestCycle cycle, Exception ex) {}
Optional target = cycle.find(AjaxRequestTarget.class);
//this part stopped working since it return Optional.empty(), because active
RequestHandler
//and RequestHandlerScheduledAfterCurrent are both null
if (target.isPresent()) {
return target.get();
}
IPageRequestHandler last =
PageRequestHandlerTracker.getLastHandler(RequestCycle.get());
WebPage page = (WebPage) (last.getPage());
return new RenderPageRequestHandler(new
PageProvider(currentPage));
}
Is this a wicket bug or it was intention to work like this? If it was
intentended, is there
any workaround to get the AjaxRequestTarget? Or the approach has changed in
wicket 8? Any other ideas?
Matus
Táto správa je určená iba pre uvedeného príjemcu a môže obsahovať dôverné alebo
interné informácie. Ak ste ju omylom obdržali, upovedomte o tom prosím
odosielateľa a vymažte ju. Akýkoľvek iný spôsob použitia tohto e-mailu je
zakázaný.
This message is for the designated recipient only and may contain confidential
or internal information. If you have received it in error, please notify the
sender immediately and delete the original. Any other use of the e-mail by you
is prohibited.
Re: Exception Handling (ajax)
Yes, indeed.
Sven
On 09.03.2016 15:43, Lars Törner wrote:
Hi Sven and thanks for your answer!
Ok I see! That's a better solution. I guess it means that I don't have to
set:
getExceptionSettings().setAjaxErrorHandlingStrategy(
AjaxErrorStrategy.INVOKE_FAILURE_HANDLER);
Because we'll never get to the DefaultExceptionMapper (in the case of an
expected unexpected exception).
Cheers
Lars
2016-03-09 10:56 GMT+01:00 Sven Meier <s...@meiers.net>:
Hi Lars,
if this is a good or bad way to handle exceptions during ajax requests
I'd keep your IRequestCycleListener and just return new
ErrorCodeRequestHandler(500, message) from there.
No need to fiddle with IExceptionMapper and/or DefaultExceptionMapper.
Have fun
Sven
On 09.03.2016 09:33, Lars Törner wrote:
About exception handling
I would like a fallback for unexcpected exceptions that are thrown during
ajax-calls.
I don't want to redirect to a new page so in my application#init I do:
getExceptionSettings().setAjaxErrorHandlingStrategy(AjaxErrorStrategy.INVOKE_FAILURE_HANDLER);
For the moment I have a request cycle listener for exceptions (added also
in application#init). Which implements #onException but for now does
nothing if an ajax-request is running:
!((WebRequest) requestCycle.getRequest()).isAjax()) -> return null
AjaxErrorStrategy.INVOKE_FAILURE_HANDLER leads to
org.apache.wicket.DefaultExceptionMapper.internalMap(Exception) returns
ErrorCodeRequestHandler(500)
What I would like is to register a global failure handler that via java
script shows a nice toaster with a user friendly message:
Wicket.Event.subscribe('/ajax/call/failure',
function (jqEvent, attributes, jqXHR, errorThrown, textStatus)
{
//TODO Show a fancy toaster with a nice localized user error message
});
ErrorCodeRequestHandler above has also a constructor that takes a message:
ErrorCodeRequestHandler(final int errorCode, final String message)
I guess this can be used to get the nice message to the browser?
So when I write this an do some more thinking my conclusion is that I must
implement my own IExceptionMapper (extending DefaultExceptionMapper?).
I will then create my new ExceptionMapper in MyApplication#init and
override Application#getExceptionMapperProvider() to return it. In my
exception mapper I can check all types of unexpected exeptions my
application might throw and get the corresponding user message to supply
it
to ErrorCodeRequestHandler(final int errorCode, final String message) and
then let failure handler show it in the toaster.
Ok, so now I guess it would be easier to just test this, but the mail is
written so I hope I don´t waste to much of your time by asking if this is
a
good or bad way to handle exceptions during ajax requests.
Cheers
Lasse
-
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: Exception Handling (ajax)
Hi Sven and thanks for your answer!
Ok I see! That's a better solution. I guess it means that I don't have to
set:
getExceptionSettings().setAjaxErrorHandlingStrategy(
AjaxErrorStrategy.INVOKE_FAILURE_HANDLER);
Because we'll never get to the DefaultExceptionMapper (in the case of an
expected unexpected exception).
Cheers
Lars
2016-03-09 10:56 GMT+01:00 Sven Meier <s...@meiers.net>:
> Hi Lars,
>
> > if this is a good or bad way to handle exceptions during ajax requests
>
> I'd keep your IRequestCycleListener and just return new
> ErrorCodeRequestHandler(500, message) from there.
> No need to fiddle with IExceptionMapper and/or DefaultExceptionMapper.
>
> Have fun
> Sven
>
>
>
>
> On 09.03.2016 09:33, Lars Törner wrote:
>
>> About exception handling
>>
>> I would like a fallback for unexcpected exceptions that are thrown during
>> ajax-calls.
>>
>> I don't want to redirect to a new page so in my application#init I do:
>>
>>
>> getExceptionSettings().setAjaxErrorHandlingStrategy(AjaxErrorStrategy.INVOKE_FAILURE_HANDLER);
>>
>> For the moment I have a request cycle listener for exceptions (added also
>> in application#init). Which implements #onException but for now does
>> nothing if an ajax-request is running:
>> !((WebRequest) requestCycle.getRequest()).isAjax()) -> return null
>>
>> AjaxErrorStrategy.INVOKE_FAILURE_HANDLER leads to
>> org.apache.wicket.DefaultExceptionMapper.internalMap(Exception) returns
>> ErrorCodeRequestHandler(500)
>>
>> What I would like is to register a global failure handler that via java
>> script shows a nice toaster with a user friendly message:
>>
>> Wicket.Event.subscribe('/ajax/call/failure',
>> function (jqEvent, attributes, jqXHR, errorThrown, textStatus)
>> {
>>//TODO Show a fancy toaster with a nice localized user error message
>> });
>>
>> ErrorCodeRequestHandler above has also a constructor that takes a message:
>> ErrorCodeRequestHandler(final int errorCode, final String message)
>>
>> I guess this can be used to get the nice message to the browser?
>>
>> So when I write this an do some more thinking my conclusion is that I must
>> implement my own IExceptionMapper (extending DefaultExceptionMapper?).
>>
>> I will then create my new ExceptionMapper in MyApplication#init and
>> override Application#getExceptionMapperProvider() to return it. In my
>> exception mapper I can check all types of unexpected exeptions my
>> application might throw and get the corresponding user message to supply
>> it
>> to ErrorCodeRequestHandler(final int errorCode, final String message) and
>> then let failure handler show it in the toaster.
>>
>> Ok, so now I guess it would be easier to just test this, but the mail is
>> written so I hope I don´t waste to much of your time by asking if this is
>> a
>> good or bad way to handle exceptions during ajax requests.
>>
>> Cheers
>> Lasse
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Re: Exception Handling (ajax)
Hi Lars,
> if this is a good or bad way to handle exceptions during ajax requests
I'd keep your IRequestCycleListener and just return new
ErrorCodeRequestHandler(500, message) from there.
No need to fiddle with IExceptionMapper and/or DefaultExceptionMapper.
Have fun
Sven
On 09.03.2016 09:33, Lars Törner wrote:
About exception handling
I would like a fallback for unexcpected exceptions that are thrown during
ajax-calls.
I don't want to redirect to a new page so in my application#init I do:
getExceptionSettings().setAjaxErrorHandlingStrategy(AjaxErrorStrategy.INVOKE_FAILURE_HANDLER);
For the moment I have a request cycle listener for exceptions (added also
in application#init). Which implements #onException but for now does
nothing if an ajax-request is running:
!((WebRequest) requestCycle.getRequest()).isAjax()) -> return null
AjaxErrorStrategy.INVOKE_FAILURE_HANDLER leads to
org.apache.wicket.DefaultExceptionMapper.internalMap(Exception) returns
ErrorCodeRequestHandler(500)
What I would like is to register a global failure handler that via java
script shows a nice toaster with a user friendly message:
Wicket.Event.subscribe('/ajax/call/failure',
function (jqEvent, attributes, jqXHR, errorThrown, textStatus)
{
//TODO Show a fancy toaster with a nice localized user error message
});
ErrorCodeRequestHandler above has also a constructor that takes a message:
ErrorCodeRequestHandler(final int errorCode, final String message)
I guess this can be used to get the nice message to the browser?
So when I write this an do some more thinking my conclusion is that I must
implement my own IExceptionMapper (extending DefaultExceptionMapper?).
I will then create my new ExceptionMapper in MyApplication#init and
override Application#getExceptionMapperProvider() to return it. In my
exception mapper I can check all types of unexpected exeptions my
application might throw and get the corresponding user message to supply it
to ErrorCodeRequestHandler(final int errorCode, final String message) and
then let failure handler show it in the toaster.
Ok, so now I guess it would be easier to just test this, but the mail is
written so I hope I don´t waste to much of your time by asking if this is a
good or bad way to handle exceptions during ajax requests.
Cheers
Lasse
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Exception Handling (ajax)
About exception handling
I would like a fallback for unexcpected exceptions that are thrown during
ajax-calls.
I don't want to redirect to a new page so in my application#init I do:
getExceptionSettings().setAjaxErrorHandlingStrategy(AjaxErrorStrategy.INVOKE_FAILURE_HANDLER);
For the moment I have a request cycle listener for exceptions (added also
in application#init). Which implements #onException but for now does
nothing if an ajax-request is running:
!((WebRequest) requestCycle.getRequest()).isAjax()) -> return null
AjaxErrorStrategy.INVOKE_FAILURE_HANDLER leads to
org.apache.wicket.DefaultExceptionMapper.internalMap(Exception) returns
ErrorCodeRequestHandler(500)
What I would like is to register a global failure handler that via java
script shows a nice toaster with a user friendly message:
Wicket.Event.subscribe('/ajax/call/failure',
function (jqEvent, attributes, jqXHR, errorThrown, textStatus)
{
//TODO Show a fancy toaster with a nice localized user error message
});
ErrorCodeRequestHandler above has also a constructor that takes a message:
ErrorCodeRequestHandler(final int errorCode, final String message)
I guess this can be used to get the nice message to the browser?
So when I write this an do some more thinking my conclusion is that I must
implement my own IExceptionMapper (extending DefaultExceptionMapper?).
I will then create my new ExceptionMapper in MyApplication#init and
override Application#getExceptionMapperProvider() to return it. In my
exception mapper I can check all types of unexpected exeptions my
application might throw and get the corresponding user message to supply it
to ErrorCodeRequestHandler(final int errorCode, final String message) and
then let failure handler show it in the toaster.
Ok, so now I guess it would be easier to just test this, but the mail is
written so I hope I don´t waste to much of your time by asking if this is a
good or bad way to handle exceptions during ajax requests.
Cheers
Lasse
Re: Exception handling in AutoCompleteTextField
Hi, After looking into ajax code a bit, I see that 'Ajax-Location' header is not considered for autocomplete response. I created a PR (https://github.com/apache/wicket/pull/156) with a small change to ajax JavaScript. Regards, Rakesh.A -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Exception-handling-in-AutoCompleteTextField-tp4673192p4673272.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: Exception handling in AutoCompleteTextField
Hi, The error handling in Ajax is controlled via org.apache.wicket.settings.ExceptionSettings#setAjaxErrorHandlingStrategy(). By default it redirects to the error page. http://examples7x.wicket.apache.org/ajax/links shows both ways. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, Jan 6, 2016 at 10:39 AM, Rakesh A <iamrakes...@rediffmail.com> wrote: > Hi, > > If we get an exception while preparing suggestions/choices for the entered > text (in AutoCompleteTextField#getChoices()), I see that, there is no means > to show it to user. > JavaScript implementation handles only success responses. > > Is there any way to execute standard Ajax response handling, in this case? > > Please find attached quick start, try entering 'test' in the autocomplete > text field on home page. > > autocomplete.7z > <http://apache-wicket.1842946.n4.nabble.com/file/n4673192/autocomplete.7z> > > Regards, > Rakesh.A > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Exception-handling-in-AutoCompleteTextField-tp4673192.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 > >
Exception handling in AutoCompleteTextField
Hi, If we get an exception while preparing suggestions/choices for the entered text (in AutoCompleteTextField#getChoices()), I see that, there is no means to show it to user. JavaScript implementation handles only success responses. Is there any way to execute standard Ajax response handling, in this case? Please find attached quick start, try entering 'test' in the autocomplete text field on home page. autocomplete.7z <http://apache-wicket.1842946.n4.nabble.com/file/n4673192/autocomplete.7z> Regards, Rakesh.A -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Exception-handling-in-AutoCompleteTextField-tp4673192.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
Ajax exception handling on client side
Hi, How can I handle exceptions occurred at the server side on the client side (with Ajax requests)? At the client side, the javascript event ' /ajax/call/failure' is only fired when the connection fails (I think), but when the there's an unhandled exception on the server side, the events ' /ajax/call/success' and '/ajax/call/complete' fired with a redirect message. I know I can just try...catch each ajax component, but I was looking for something more global to the whole application. Can anyone help me? -- André Camilo Software Architect Premium Minds Av. Marquês de Tomar nº69, 1º Andar 1050-154 Lisboa www.premium-minds.comhttp://www.premium-minds.com/ Geral: +351 217 817 555 Tlm: +351 914 515 010 andre.cam...@premium-minds.commailto:andre.cam...@premium-minds.com
Re: Ajax exception handling on client side
Hi, See org.apache.wicket.settings.IExceptionSettings#setAjaxErrorHandlingStrategy Martin Grigorov Wicket Training and Consulting On Fri, May 30, 2014 at 12:46 PM, Andre Camilo andre.cam...@premium-minds.com wrote: Hi, How can I handle exceptions occurred at the server side on the client side (with Ajax requests)? At the client side, the javascript event ' /ajax/call/failure' is only fired when the connection fails (I think), but when the there's an unhandled exception on the server side, the events ' /ajax/call/success' and '/ajax/call/complete' fired with a redirect message. I know I can just try...catch each ajax component, but I was looking for something more global to the whole application. Can anyone help me? -- André Camilo Software Architect Premium Minds Av. Marquês de Tomar nº69, 1º Andar 1050-154 Lisboa www.premium-minds.comhttp://www.premium-minds.com/ Geral: +351 217 817 555 Tlm: +351 914 515 010 andre.cam...@premium-minds.commailto:andre.cam...@premium-minds.com
onInitialize() and exception handling
Hi, I have a wicket application where I create page components (mainly labels and ListViews) using onInitialize() method of some panels I have in every page. In some cases, during the creation of the components, some exceptions can occur (for example if the content is downloaded from a webservice that returns error 404), and I would propagate it, but onInitialize() of Panel does not throw exceptions. So my questions are: which are the best practices to deal that cases? Is onInitialize() the best place where create components? Regards Alberto - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: onInitialize() and exception handling
You can throw any exception that extends RuntimeException François Meillet Formation Wicket - Développement Wicket Le 29 avr. 2014 à 14:35, Alberto Brosich abros...@ogs.trieste.it a écrit : Hi, I have a wicket application where I create page components (mainly labels and ListViews) using onInitialize() method of some panels I have in every page. In some cases, during the creation of the components, some exceptions can occur (for example if the content is downloaded from a webservice that returns error 404), and I would propagate it, but onInitialize() of Panel does not throw exceptions. So my questions are: which are the best practices to deal that cases? Is onInitialize() the best place where create components? Regards Alberto - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Central exception handling using a custom RequestCycleListener
Hi there, we’d like to implement a centralized exception handling strategy for backend/service calls from with within Wicket components. Therefor I thought it could be a good idea to do this in a custom org.apache.wicket.request.cycle.AbstractRequestCycleListener#onException implementation. Depending on the caught exception we’d potentially like to do some cleanup logic (i.e. call methods on the currently requested page). I’m not sure what is the best strategy to get the page instance in onException, and what about ajax requests? And hints or pointers? Cheers, -Tom signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Central exception handling using a custom RequestCycleListener
Hi, You may use another IRequestCycleListener to track the last processed page - org.apache.wicket.request.cycle.PageRequestHandlerTracker Martin Grigorov Wicket Training and Consulting On Wed, Feb 19, 2014 at 5:53 PM, Tom Götz t...@decoded.de wrote: Hi there, we’d like to implement a centralized exception handling strategy for backend/service calls from with within Wicket components. Therefor I thought it could be a good idea to do this in a custom org.apache.wicket.request.cycle.AbstractRequestCycleListener#onException implementation. Depending on the caught exception we’d potentially like to do some cleanup logic (i.e. call methods on the currently requested page). I’m not sure what is the best strategy to get the page instance in onException, and what about ajax requests? And hints or pointers? Cheers, -Tom
Re: Central exception handling using a custom RequestCycleListener
Nice, I’ll have a look at that thingy ;-) Thanks, -Tom On 19.02.2014, at 16:56, Martin Grigorov mgrigo...@apache.org wrote: Hi, You may use another IRequestCycleListener to track the last processed page - org.apache.wicket.request.cycle.PageRequestHandlerTracker Martin Grigorov Wicket Training and Consulting On Wed, Feb 19, 2014 at 5:53 PM, Tom Götz t...@decoded.de wrote: Hi there, we’d like to implement a centralized exception handling strategy for backend/service calls from with within Wicket components. Therefor I thought it could be a good idea to do this in a custom org.apache.wicket.request.cycle.AbstractRequestCycleListener#onException implementation. Depending on the caught exception we’d potentially like to do some cleanup logic (i.e. call methods on the currently requested page). I’m not sure what is the best strategy to get the page instance in onException, and what about ajax requests? And hints or pointers? Cheers, -Tom signature.asc Description: Message signed with OpenPGP using GPGMail
Wicket LoadableDetachableModel exception handling issue
In my project, I am using LoadableDetachableModel as given below.
public ReportPage(final Objectm, final PageReference pr) throws
CustomException{try{final LoadableDetachableModelListMaintReport
ldm =
new LoadableDetachableModelListMaintReport() {
@Override
protected ListMaintReportload() {
**// Some Database operations //**
return x;
}
};
/*
Several LoadableDetachableModels, PageableListViews, Panels, Fragments etc.
*/ } catch ( Exception ex){// create Custom Exception } finally {
// Clean up of stuff }
My problem is that I am using AbstractColumn to display the objects in the
column and the overriden populateItem() method calls the load()
internally. Since both the methods cannot throw Exceptions, I cannot
really catch exceptions and display appropriate messages.
Any help on this is really appreciated.
--
Thanks Regards
JK
Re: Wicket LoadableDetachableModel exception handling issue
How about wrapping it to a RuntimeException, or preferably, your own
subclass of it?
Ondra
On 02/20/2013 04:51 PM, Jayakrishnan R wrote:
In my project, I am using LoadableDetachableModel as given below.
public ReportPage(final Objectm, final PageReference pr) throws
CustomException{try{final LoadableDetachableModelListMaintReport
ldm =
new LoadableDetachableModelListMaintReport() {
@Override
protected ListMaintReportload() {
**// Some Database operations //**
return x;
}
};
/*
Several LoadableDetachableModels, PageableListViews, Panels, Fragments etc.
*/ } catch ( Exception ex){// create Custom Exception } finally {
// Clean up of stuff }
My problem is that I am using AbstractColumn to display the objects in the
column and the overriden populateItem() method calls the load()
internally. Since both the methods cannot throw Exceptions, I cannot
really catch exceptions and display appropriate messages.
Any help on this is really appreciated.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket LoadableDetachableModel exception handling issue
i have already done that as a back up plan. Do you think wicket is a bit
wierd in handling exceptions.
On 20 Feb 2013 16:22, Ondrej Zizka ozi...@redhat.com wrote:
How about wrapping it to a RuntimeException, or preferably, your own
subclass of it?
Ondra
On 02/20/2013 04:51 PM, Jayakrishnan R wrote:
In my project, I am using LoadableDetachableModel as given below.
public ReportPage(final Objectm, final PageReference pr) throws
CustomException{try{final LoadableDetachableModelList**MaintReport
ldm =
new LoadableDetachableModelList**MaintReport() {
@Override
protected ListMaintReportload() {
**// Some Database operations //**
return x;
}
};
/*
Several LoadableDetachableModels, PageableListViews, Panels, Fragments
etc.
*/ } catch ( Exception ex){// create Custom Exception } finally {
// Clean up of stuff }
My problem is that I am using AbstractColumn to display the objects in the
column and the overriden populateItem() method calls the load()
internally. Since both the methods cannot throw Exceptions, I cannot
really catch exceptions and display appropriate messages.
Any help on this is really appreciated.
Re: Wicket LoadableDetachableModel exception handling issue
Actually I think Wicket offers, inherently, one of the best ways to
handle exceptions - I can catch it wherever I want, rewrap, redirect,
ignore, alter the model... I haven't seen such freedom and versatility
in any other web framework.
YMMV.
Ondra
On 02/20/2013 05:39 PM, Jayakrishnan R wrote:
i have already done that as a back up plan. Do you think wicket is a
bit wierd in handling exceptions.
On 20 Feb 2013 16:22, Ondrej Zizka ozi...@redhat.com
mailto:ozi...@redhat.com wrote:
How about wrapping it to a RuntimeException, or preferably, your
own subclass of it?
Ondra
On 02/20/2013 04:51 PM, Jayakrishnan R wrote:
In my project, I am using LoadableDetachableModel as given below.
public ReportPage(final Objectm, final PageReference pr) throws
CustomException{try{final
LoadableDetachableModelListMaintReport
ldm =
new LoadableDetachableModelListMaintReport() {
@Override
protected ListMaintReportload() {
**// Some Database operations //**
return x;
}
};
/*
Several LoadableDetachableModels, PageableListViews, Panels,
Fragments etc.
*/ } catch ( Exception ex){// create Custom Exception } finally {
// Clean up of stuff }
My problem is that I am using AbstractColumn to display the
objects in the
column and the overriden populateItem() method calls the load()
internally. Since both the methods cannot throw Exceptions, I
cannot
really catch exceptions and display appropriate messages.
Any help on this is really appreciated.
Re: Exception handling and testing
Make the TabbedPanel stateless by using BookmarkablePageLink.
P.S. Please start a new thread when you have new questions.
On Wed, Sep 26, 2012 at 10:56 PM, Alec Swan alecs...@gmail.com wrote:
Thanks, that worked as advertised. Now I am wondering if it's possible
to get this to work when the user click on a tab in TabbedPanel?
RenderPageRequestHandler(new PageProvider(HomePage.class),
ALWAYS_REDIRECT) seems to lose the knowledge of the tab selected by
the user and redirects the user to the default tab after he logs in on
HomePage.
Thoughts?
Thanks,
Alec
On Wed, Sep 26, 2012 at 12:52 AM, Martin Grigorov mgrigo...@apache.org
wrote:
You have to return a IRequestHandler. See RenderPageRequestHandler
On Wed, Sep 26, 2012 at 1:45 AM, Alec Swan alecs...@gmail.com wrote:
I am trying to implement Martin's @SubSite annotation approach to
redirect the user to the sub-site's home page when
AuthenticationException is thrown in Wicket 1.5. However, apparently I
cannot throw a
RestartResponseAtInterceptPageException(annotation.homePage())
from AbstractRequestCycleListener#onException. How else can I redirect
the user to the sub-site login page?
The following RCH causes a 500 HTTP error page to be shown in the
browser when AuthenticationException is thrown.
public class AuthenticationExceptionRequestCycleHandler extends
AbstractRequestCycleListener
{
@Override
public IRequestHandler onException(RequestCycle cycle, Exception ex) {
if (ex instanceof WicketRuntimeException
ex.getCause().getCause() instanceof AuthenticationException) {
IPageRequestHandler lastHandler =
PageRequestHandlerTracker.getLastHandler(cycle);
Class? extends IRequestablePage pageClass = lastHandler
== null ? null : lastHandler.getPageClass();
if (pageClass != null) {
SubSite annotation = pageClass.getAnnotation(SubSite.class);
if (annotation != null annotation.homePage() != null) {
throw new
RestartResponseAtInterceptPageException(annotation.homePage());
}
}
}
return super.onException(cycle, ex);
}
}
Thanks,
Alec
On Fri, Jun 8, 2012 at 2:54 PM, Alec Swan alecs...@gmail.com wrote:
I also use this approach, but with authentication exceptions thrown by
Wicket it's hard to tell if the user was redirected to Login page
because of authentication or some other exceptions.
On Fri, Jun 8, 2012 at 1:15 PM, Michal Margiel michal.marg...@gmail.com
wrote:
2012/6/8 Alec Swan alecs...@gmail.com
That's clever. I will give it a try.
What is the recommendation on verifying that an exception was thrown
during page rendering using Wicket tester? I am not talking just about
authentication here, but exceptions in general.
Hello,
Why you want to verify that exception was thrown in WicketTester? IMHO it
is not proper place to check that.
In my code I am verifying expcetions in services tests using
catch-exception library [1].
And then while testing Page I am mocking my service to throw exception and
I am verifying behaviour on exception (e.g. redirecting to login page,
showing error message etc...)
That makes not only clearer code but also simplify testing.
you can see example of services tests in [2] and page tests in [3]
[1] http://code.google.com/p/catch-exception/
[2]
https://bitbucket.org/margielm/confitura/src/8599eae2ba00/src/test/java/jelatyna/services/UserServiceImplShould.java
[3]
https://bitbucket.org/margielm/confitura/src/8599eae2ba00/src/test/java/jelatyna/pages/admin/login/LoginPageShould.java
--
Pozdrawiam/Best regards
Michał Margiel
http://www.confitura.pl (dawniej Javarsovia)
http://www.linkedin.com/in/MichalMargiel
http://www.margiel.eu
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.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
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Exception handling and testing
Thanks, works great.
I just needed to convert IRequestParameters to PageParameters in
RequestHandler#onException() in order to remember the tab selection
made by the user throughout login. Is there a convenience method
somewhere in wicket to convert between IRequestParameters and
PageParameters?
Thanks,
Ale
On Thu, Sep 27, 2012 at 1:18 AM, Martin Grigorov mgrigo...@apache.org wrote:
Make the TabbedPanel stateless by using BookmarkablePageLink.
P.S. Please start a new thread when you have new questions.
On Wed, Sep 26, 2012 at 10:56 PM, Alec Swan alecs...@gmail.com wrote:
Thanks, that worked as advertised. Now I am wondering if it's possible
to get this to work when the user click on a tab in TabbedPanel?
RenderPageRequestHandler(new PageProvider(HomePage.class),
ALWAYS_REDIRECT) seems to lose the knowledge of the tab selected by
the user and redirects the user to the default tab after he logs in on
HomePage.
Thoughts?
Thanks,
Alec
On Wed, Sep 26, 2012 at 12:52 AM, Martin Grigorov mgrigo...@apache.org
wrote:
You have to return a IRequestHandler. See RenderPageRequestHandler
On Wed, Sep 26, 2012 at 1:45 AM, Alec Swan alecs...@gmail.com wrote:
I am trying to implement Martin's @SubSite annotation approach to
redirect the user to the sub-site's home page when
AuthenticationException is thrown in Wicket 1.5. However, apparently I
cannot throw a
RestartResponseAtInterceptPageException(annotation.homePage())
from AbstractRequestCycleListener#onException. How else can I redirect
the user to the sub-site login page?
The following RCH causes a 500 HTTP error page to be shown in the
browser when AuthenticationException is thrown.
public class AuthenticationExceptionRequestCycleHandler extends
AbstractRequestCycleListener
{
@Override
public IRequestHandler onException(RequestCycle cycle, Exception ex) {
if (ex instanceof WicketRuntimeException
ex.getCause().getCause() instanceof AuthenticationException) {
IPageRequestHandler lastHandler =
PageRequestHandlerTracker.getLastHandler(cycle);
Class? extends IRequestablePage pageClass = lastHandler
== null ? null : lastHandler.getPageClass();
if (pageClass != null) {
SubSite annotation =
pageClass.getAnnotation(SubSite.class);
if (annotation != null annotation.homePage() != null) {
throw new
RestartResponseAtInterceptPageException(annotation.homePage());
}
}
}
return super.onException(cycle, ex);
}
}
Thanks,
Alec
On Fri, Jun 8, 2012 at 2:54 PM, Alec Swan alecs...@gmail.com wrote:
I also use this approach, but with authentication exceptions thrown by
Wicket it's hard to tell if the user was redirected to Login page
because of authentication or some other exceptions.
On Fri, Jun 8, 2012 at 1:15 PM, Michal Margiel michal.marg...@gmail.com
wrote:
2012/6/8 Alec Swan alecs...@gmail.com
That's clever. I will give it a try.
What is the recommendation on verifying that an exception was thrown
during page rendering using Wicket tester? I am not talking just about
authentication here, but exceptions in general.
Hello,
Why you want to verify that exception was thrown in WicketTester? IMHO it
is not proper place to check that.
In my code I am verifying expcetions in services tests using
catch-exception library [1].
And then while testing Page I am mocking my service to throw exception
and
I am verifying behaviour on exception (e.g. redirecting to login page,
showing error message etc...)
That makes not only clearer code but also simplify testing.
you can see example of services tests in [2] and page tests in [3]
[1] http://code.google.com/p/catch-exception/
[2]
https://bitbucket.org/margielm/confitura/src/8599eae2ba00/src/test/java/jelatyna/services/UserServiceImplShould.java
[3]
https://bitbucket.org/margielm/confitura/src/8599eae2ba00/src/test/java/jelatyna/pages/admin/login/LoginPageShould.java
--
Pozdrawiam/Best regards
Michał Margiel
http://www.confitura.pl (dawniej Javarsovia)
http://www.linkedin.com/in/MichalMargiel
http://www.margiel.eu
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.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
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: Exception handling and testing
You have to return a IRequestHandler. See RenderPageRequestHandler
On Wed, Sep 26, 2012 at 1:45 AM, Alec Swan alecs...@gmail.com wrote:
I am trying to implement Martin's @SubSite annotation approach to
redirect the user to the sub-site's home page when
AuthenticationException is thrown in Wicket 1.5. However, apparently I
cannot throw a RestartResponseAtInterceptPageException(annotation.homePage())
from AbstractRequestCycleListener#onException. How else can I redirect
the user to the sub-site login page?
The following RCH causes a 500 HTTP error page to be shown in the
browser when AuthenticationException is thrown.
public class AuthenticationExceptionRequestCycleHandler extends
AbstractRequestCycleListener
{
@Override
public IRequestHandler onException(RequestCycle cycle, Exception ex) {
if (ex instanceof WicketRuntimeException
ex.getCause().getCause() instanceof AuthenticationException) {
IPageRequestHandler lastHandler =
PageRequestHandlerTracker.getLastHandler(cycle);
Class? extends IRequestablePage pageClass = lastHandler
== null ? null : lastHandler.getPageClass();
if (pageClass != null) {
SubSite annotation = pageClass.getAnnotation(SubSite.class);
if (annotation != null annotation.homePage() != null) {
throw new
RestartResponseAtInterceptPageException(annotation.homePage());
}
}
}
return super.onException(cycle, ex);
}
}
Thanks,
Alec
On Fri, Jun 8, 2012 at 2:54 PM, Alec Swan alecs...@gmail.com wrote:
I also use this approach, but with authentication exceptions thrown by
Wicket it's hard to tell if the user was redirected to Login page
because of authentication or some other exceptions.
On Fri, Jun 8, 2012 at 1:15 PM, Michal Margiel michal.marg...@gmail.com
wrote:
2012/6/8 Alec Swan alecs...@gmail.com
That's clever. I will give it a try.
What is the recommendation on verifying that an exception was thrown
during page rendering using Wicket tester? I am not talking just about
authentication here, but exceptions in general.
Hello,
Why you want to verify that exception was thrown in WicketTester? IMHO it
is not proper place to check that.
In my code I am verifying expcetions in services tests using
catch-exception library [1].
And then while testing Page I am mocking my service to throw exception and
I am verifying behaviour on exception (e.g. redirecting to login page,
showing error message etc...)
That makes not only clearer code but also simplify testing.
you can see example of services tests in [2] and page tests in [3]
[1] http://code.google.com/p/catch-exception/
[2]
https://bitbucket.org/margielm/confitura/src/8599eae2ba00/src/test/java/jelatyna/services/UserServiceImplShould.java
[3]
https://bitbucket.org/margielm/confitura/src/8599eae2ba00/src/test/java/jelatyna/pages/admin/login/LoginPageShould.java
--
Pozdrawiam/Best regards
Michał Margiel
http://www.confitura.pl (dawniej Javarsovia)
http://www.linkedin.com/in/MichalMargiel
http://www.margiel.eu
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Exception handling and testing
Thanks, that worked as advertised. Now I am wondering if it's possible
to get this to work when the user click on a tab in TabbedPanel?
RenderPageRequestHandler(new PageProvider(HomePage.class),
ALWAYS_REDIRECT) seems to lose the knowledge of the tab selected by
the user and redirects the user to the default tab after he logs in on
HomePage.
Thoughts?
Thanks,
Alec
On Wed, Sep 26, 2012 at 12:52 AM, Martin Grigorov mgrigo...@apache.org wrote:
You have to return a IRequestHandler. See RenderPageRequestHandler
On Wed, Sep 26, 2012 at 1:45 AM, Alec Swan alecs...@gmail.com wrote:
I am trying to implement Martin's @SubSite annotation approach to
redirect the user to the sub-site's home page when
AuthenticationException is thrown in Wicket 1.5. However, apparently I
cannot throw a RestartResponseAtInterceptPageException(annotation.homePage())
from AbstractRequestCycleListener#onException. How else can I redirect
the user to the sub-site login page?
The following RCH causes a 500 HTTP error page to be shown in the
browser when AuthenticationException is thrown.
public class AuthenticationExceptionRequestCycleHandler extends
AbstractRequestCycleListener
{
@Override
public IRequestHandler onException(RequestCycle cycle, Exception ex) {
if (ex instanceof WicketRuntimeException
ex.getCause().getCause() instanceof AuthenticationException) {
IPageRequestHandler lastHandler =
PageRequestHandlerTracker.getLastHandler(cycle);
Class? extends IRequestablePage pageClass = lastHandler
== null ? null : lastHandler.getPageClass();
if (pageClass != null) {
SubSite annotation = pageClass.getAnnotation(SubSite.class);
if (annotation != null annotation.homePage() != null) {
throw new
RestartResponseAtInterceptPageException(annotation.homePage());
}
}
}
return super.onException(cycle, ex);
}
}
Thanks,
Alec
On Fri, Jun 8, 2012 at 2:54 PM, Alec Swan alecs...@gmail.com wrote:
I also use this approach, but with authentication exceptions thrown by
Wicket it's hard to tell if the user was redirected to Login page
because of authentication or some other exceptions.
On Fri, Jun 8, 2012 at 1:15 PM, Michal Margiel michal.marg...@gmail.com
wrote:
2012/6/8 Alec Swan alecs...@gmail.com
That's clever. I will give it a try.
What is the recommendation on verifying that an exception was thrown
during page rendering using Wicket tester? I am not talking just about
authentication here, but exceptions in general.
Hello,
Why you want to verify that exception was thrown in WicketTester? IMHO it
is not proper place to check that.
In my code I am verifying expcetions in services tests using
catch-exception library [1].
And then while testing Page I am mocking my service to throw exception and
I am verifying behaviour on exception (e.g. redirecting to login page,
showing error message etc...)
That makes not only clearer code but also simplify testing.
you can see example of services tests in [2] and page tests in [3]
[1] http://code.google.com/p/catch-exception/
[2]
https://bitbucket.org/margielm/confitura/src/8599eae2ba00/src/test/java/jelatyna/services/UserServiceImplShould.java
[3]
https://bitbucket.org/margielm/confitura/src/8599eae2ba00/src/test/java/jelatyna/pages/admin/login/LoginPageShould.java
--
Pozdrawiam/Best regards
Michał Margiel
http://www.confitura.pl (dawniej Javarsovia)
http://www.linkedin.com/in/MichalMargiel
http://www.margiel.eu
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.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: Exception handling and testing
I am trying to implement Martin's @SubSite annotation approach to
redirect the user to the sub-site's home page when
AuthenticationException is thrown in Wicket 1.5. However, apparently I
cannot throw a RestartResponseAtInterceptPageException(annotation.homePage())
from AbstractRequestCycleListener#onException. How else can I redirect
the user to the sub-site login page?
The following RCH causes a 500 HTTP error page to be shown in the
browser when AuthenticationException is thrown.
public class AuthenticationExceptionRequestCycleHandler extends
AbstractRequestCycleListener
{
@Override
public IRequestHandler onException(RequestCycle cycle, Exception ex) {
if (ex instanceof WicketRuntimeException
ex.getCause().getCause() instanceof AuthenticationException) {
IPageRequestHandler lastHandler =
PageRequestHandlerTracker.getLastHandler(cycle);
Class? extends IRequestablePage pageClass = lastHandler
== null ? null : lastHandler.getPageClass();
if (pageClass != null) {
SubSite annotation = pageClass.getAnnotation(SubSite.class);
if (annotation != null annotation.homePage() != null) {
throw new
RestartResponseAtInterceptPageException(annotation.homePage());
}
}
}
return super.onException(cycle, ex);
}
}
Thanks,
Alec
On Fri, Jun 8, 2012 at 2:54 PM, Alec Swan alecs...@gmail.com wrote:
I also use this approach, but with authentication exceptions thrown by
Wicket it's hard to tell if the user was redirected to Login page
because of authentication or some other exceptions.
On Fri, Jun 8, 2012 at 1:15 PM, Michal Margiel michal.marg...@gmail.com
wrote:
2012/6/8 Alec Swan alecs...@gmail.com
That's clever. I will give it a try.
What is the recommendation on verifying that an exception was thrown
during page rendering using Wicket tester? I am not talking just about
authentication here, but exceptions in general.
Hello,
Why you want to verify that exception was thrown in WicketTester? IMHO it
is not proper place to check that.
In my code I am verifying expcetions in services tests using
catch-exception library [1].
And then while testing Page I am mocking my service to throw exception and
I am verifying behaviour on exception (e.g. redirecting to login page,
showing error message etc...)
That makes not only clearer code but also simplify testing.
you can see example of services tests in [2] and page tests in [3]
[1] http://code.google.com/p/catch-exception/
[2]
https://bitbucket.org/margielm/confitura/src/8599eae2ba00/src/test/java/jelatyna/services/UserServiceImplShould.java
[3]
https://bitbucket.org/margielm/confitura/src/8599eae2ba00/src/test/java/jelatyna/pages/admin/login/LoginPageShould.java
--
Pozdrawiam/Best regards
Michał Margiel
http://www.confitura.pl (dawniej Javarsovia)
http://www.linkedin.com/in/MichalMargiel
http://www.margiel.eu
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: exception handling (get cause page)
It works perfectly thanks
On Mon, Sep 3, 2012 at 3:11 PM, Martin Grigorov mgrigo...@apache.org wrote:
Hi,
See
https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/request/cycle/PageRequestHandlerTracker.java
Register it, then use it:
PageRequestHandlerTracker.getLastHandler(cycle).getPage()
On Mon, Sep 3, 2012 at 8:00 PM, Alfonso Quiroga alfonsose...@gmail.com
wrote:
Hi! I have a custom exception handler, and I have this method:
onException(RequestCycle cycle, Exception anException) {
}
Inside this method, how can I get the original page who caused the
exception? in other Wicket version, I had onRuntimeException
method, who already had the original page.
Thanks in advance!
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.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
exception handling (get cause page)
Hi! I have a custom exception handler, and I have this method:
onException(RequestCycle cycle, Exception anException) {
}
Inside this method, how can I get the original page who caused the
exception? in other Wicket version, I had onRuntimeException
method, who already had the original page.
Thanks in advance!
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: exception handling (get cause page)
Hi,
See
https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/request/cycle/PageRequestHandlerTracker.java
Register it, then use it:
PageRequestHandlerTracker.getLastHandler(cycle).getPage()
On Mon, Sep 3, 2012 at 8:00 PM, Alfonso Quiroga alfonsose...@gmail.com wrote:
Hi! I have a custom exception handler, and I have this method:
onException(RequestCycle cycle, Exception anException) {
}
Inside this method, how can I get the original page who caused the
exception? in other Wicket version, I had onRuntimeException
method, who already had the original page.
Thanks in advance!
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Exception handling and testing
That's clever. I will give it a try. What is the recommendation on verifying that an exception was thrown during page rendering using Wicket tester? I am not talking just about authentication here, but exceptions in general. Thanks, Alec On Thu, Jun 7, 2012 at 6:18 PM, Martin Grigorov mgrigo...@apache.org wrote: On Fri, Jun 8, 2012 at 12:37 AM, Alec Swan alecs...@gmail.com wrote: I am also asking how to redirect to sub-site's home page when the user is not authenticated and tries to access on of those sub-site pages. Use a custom IAuthenticationStrategy that knows which pages are part of this sub-site (e.g. you can annotate them with a special @SubSite) and if the user is not logged in then redirect to @SubSite.homePage class. This way even every page can it have its own home page. On Thu, Jun 7, 2012 at 3:35 PM, Alec Swan alecs...@gmail.com wrote: The problem is that I cannot verify this exception in tests. I am basically asking for best practices. Thanks! On Thu, Jun 7, 2012 at 1:30 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, You can use IAuthenticationStrategy and throw RestartResponseAtInterceptException. On Wed, Jun 6, 2012 at 8:09 PM, Alec Swan alecs...@gmail.com wrote: Hello, I am creating a new set of pages that are a part of an old project but have a different home page. It's kind of like a sub-site within a site. The user is required to log in on the sub-site's home page to be able to access any of those pages. If the user tries to access any of these pages directly he should be redirected to the sub-site's home page. What's the best way to implement/configure the home page for this sub-site? What kind of exception should each sub-site page throw to trigger redirection to home page? How can I verify that an exception was thrown in my test? (Currently I have a test which calls startPanel(..) which logs an exception if the user is not logged in, but returns with no errors. So, I have to verify that the rendered page is what it should be.) I am basically looking for best practices here. Thanks, Alec - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.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 -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.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: Exception handling and testing
2012/6/8 Alec Swan alecs...@gmail.com That's clever. I will give it a try. What is the recommendation on verifying that an exception was thrown during page rendering using Wicket tester? I am not talking just about authentication here, but exceptions in general. Hello, Why you want to verify that exception was thrown in WicketTester? IMHO it is not proper place to check that. In my code I am verifying expcetions in services tests using catch-exception library [1]. And then while testing Page I am mocking my service to throw exception and I am verifying behaviour on exception (e.g. redirecting to login page, showing error message etc...) That makes not only clearer code but also simplify testing. you can see example of services tests in [2] and page tests in [3] [1] http://code.google.com/p/catch-exception/ [2] https://bitbucket.org/margielm/confitura/src/8599eae2ba00/src/test/java/jelatyna/services/UserServiceImplShould.java [3] https://bitbucket.org/margielm/confitura/src/8599eae2ba00/src/test/java/jelatyna/pages/admin/login/LoginPageShould.java -- Pozdrawiam/Best regards Michał Margiel http://www.confitura.pl (dawniej Javarsovia) http://www.linkedin.com/in/MichalMargiel http://www.margiel.eu
Re: Exception handling and testing
I also use this approach, but with authentication exceptions thrown by Wicket it's hard to tell if the user was redirected to Login page because of authentication or some other exceptions. On Fri, Jun 8, 2012 at 1:15 PM, Michal Margiel michal.marg...@gmail.com wrote: 2012/6/8 Alec Swan alecs...@gmail.com That's clever. I will give it a try. What is the recommendation on verifying that an exception was thrown during page rendering using Wicket tester? I am not talking just about authentication here, but exceptions in general. Hello, Why you want to verify that exception was thrown in WicketTester? IMHO it is not proper place to check that. In my code I am verifying expcetions in services tests using catch-exception library [1]. And then while testing Page I am mocking my service to throw exception and I am verifying behaviour on exception (e.g. redirecting to login page, showing error message etc...) That makes not only clearer code but also simplify testing. you can see example of services tests in [2] and page tests in [3] [1] http://code.google.com/p/catch-exception/ [2] https://bitbucket.org/margielm/confitura/src/8599eae2ba00/src/test/java/jelatyna/services/UserServiceImplShould.java [3] https://bitbucket.org/margielm/confitura/src/8599eae2ba00/src/test/java/jelatyna/pages/admin/login/LoginPageShould.java -- Pozdrawiam/Best regards Michał Margiel http://www.confitura.pl (dawniej Javarsovia) http://www.linkedin.com/in/MichalMargiel http://www.margiel.eu - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Exception handling and testing
Hi, You can use IAuthenticationStrategy and throw RestartResponseAtInterceptException. On Wed, Jun 6, 2012 at 8:09 PM, Alec Swan alecs...@gmail.com wrote: Hello, I am creating a new set of pages that are a part of an old project but have a different home page. It's kind of like a sub-site within a site. The user is required to log in on the sub-site's home page to be able to access any of those pages. If the user tries to access any of these pages directly he should be redirected to the sub-site's home page. What's the best way to implement/configure the home page for this sub-site? What kind of exception should each sub-site page throw to trigger redirection to home page? How can I verify that an exception was thrown in my test? (Currently I have a test which calls startPanel(..) which logs an exception if the user is not logged in, but returns with no errors. So, I have to verify that the rendered page is what it should be.) I am basically looking for best practices here. Thanks, Alec - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Exception handling and testing
The problem is that I cannot verify this exception in tests. I am basically asking for best practices. Thanks! On Thu, Jun 7, 2012 at 1:30 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, You can use IAuthenticationStrategy and throw RestartResponseAtInterceptException. On Wed, Jun 6, 2012 at 8:09 PM, Alec Swan alecs...@gmail.com wrote: Hello, I am creating a new set of pages that are a part of an old project but have a different home page. It's kind of like a sub-site within a site. The user is required to log in on the sub-site's home page to be able to access any of those pages. If the user tries to access any of these pages directly he should be redirected to the sub-site's home page. What's the best way to implement/configure the home page for this sub-site? What kind of exception should each sub-site page throw to trigger redirection to home page? How can I verify that an exception was thrown in my test? (Currently I have a test which calls startPanel(..) which logs an exception if the user is not logged in, but returns with no errors. So, I have to verify that the rendered page is what it should be.) I am basically looking for best practices here. Thanks, Alec - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.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: Exception handling and testing
I am also asking how to redirect to sub-site's home page when the user is not authenticated and tries to access on of those sub-site pages. On Thu, Jun 7, 2012 at 3:35 PM, Alec Swan alecs...@gmail.com wrote: The problem is that I cannot verify this exception in tests. I am basically asking for best practices. Thanks! On Thu, Jun 7, 2012 at 1:30 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, You can use IAuthenticationStrategy and throw RestartResponseAtInterceptException. On Wed, Jun 6, 2012 at 8:09 PM, Alec Swan alecs...@gmail.com wrote: Hello, I am creating a new set of pages that are a part of an old project but have a different home page. It's kind of like a sub-site within a site. The user is required to log in on the sub-site's home page to be able to access any of those pages. If the user tries to access any of these pages directly he should be redirected to the sub-site's home page. What's the best way to implement/configure the home page for this sub-site? What kind of exception should each sub-site page throw to trigger redirection to home page? How can I verify that an exception was thrown in my test? (Currently I have a test which calls startPanel(..) which logs an exception if the user is not logged in, but returns with no errors. So, I have to verify that the rendered page is what it should be.) I am basically looking for best practices here. Thanks, Alec - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.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: Exception handling and testing
On Fri, Jun 8, 2012 at 12:37 AM, Alec Swan alecs...@gmail.com wrote: I am also asking how to redirect to sub-site's home page when the user is not authenticated and tries to access on of those sub-site pages. Use a custom IAuthenticationStrategy that knows which pages are part of this sub-site (e.g. you can annotate them with a special @SubSite) and if the user is not logged in then redirect to @SubSite.homePage class. This way even every page can it have its own home page. On Thu, Jun 7, 2012 at 3:35 PM, Alec Swan alecs...@gmail.com wrote: The problem is that I cannot verify this exception in tests. I am basically asking for best practices. Thanks! On Thu, Jun 7, 2012 at 1:30 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, You can use IAuthenticationStrategy and throw RestartResponseAtInterceptException. On Wed, Jun 6, 2012 at 8:09 PM, Alec Swan alecs...@gmail.com wrote: Hello, I am creating a new set of pages that are a part of an old project but have a different home page. It's kind of like a sub-site within a site. The user is required to log in on the sub-site's home page to be able to access any of those pages. If the user tries to access any of these pages directly he should be redirected to the sub-site's home page. What's the best way to implement/configure the home page for this sub-site? What kind of exception should each sub-site page throw to trigger redirection to home page? How can I verify that an exception was thrown in my test? (Currently I have a test which calls startPanel(..) which logs an exception if the user is not logged in, but returns with no errors. So, I have to verify that the rendered page is what it should be.) I am basically looking for best practices here. Thanks, Alec - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.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 -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Exception handling and testing
Hello, I am creating a new set of pages that are a part of an old project but have a different home page. It's kind of like a sub-site within a site. The user is required to log in on the sub-site's home page to be able to access any of those pages. If the user tries to access any of these pages directly he should be redirected to the sub-site's home page. What's the best way to implement/configure the home page for this sub-site? What kind of exception should each sub-site page throw to trigger redirection to home page? How can I verify that an exception was thrown in my test? (Currently I have a test which calls startPanel(..) which logs an exception if the user is not logged in, but returns with no errors. So, I have to verify that the rendered page is what it should be.) I am basically looking for best practices here. Thanks, Alec - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Exception Handling in 1.5
Hey, any idea how can I get the page/page class of the page that was being rendered when the exception happened? I was depending on that in 1.4 to determine the type of page I needed to return, for example if I am in the context of a modal window, I was showing a message in the window, and a close button. If I was in a normal page, I was showing the full error page with errors et all. I tried Class pageClass = ((IPageClassRequestHandler)cycle.getActiveRequestHandler()).getPageClass(); But that throws an NPE - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Exception Handling in 1.5
hrm. you cant yet. but you can check if you are in an ajax request or not by using webrequest.isajax() so you can implement that particular usecase without the page. -igor On Thu, Nov 17, 2011 at 1:19 PM, Nelson Segura nsegu...@gmail.com wrote: Hey, any idea how can I get the page/page class of the page that was being rendered when the exception happened? I was depending on that in 1.4 to determine the type of page I needed to return, for example if I am in the context of a modal window, I was showing a message in the window, and a close button. If I was in a normal page, I was showing the full error page with errors et all. I tried Class pageClass = ((IPageClassRequestHandler)cycle.getActiveRequestHandler()).getPageClass(); But that throws an NPE - 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: Exception Handling in 1.5
Great. Thanks for your help.
On Mon, Nov 14, 2011 at 7:06 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
application.getrequestcyclelisteners().add(new abstractrequestcyclelistener()
{
irequsthandler onexception(e) {
Throwable cause = e;
if (cause instanceof WicketRuntimeException) {
cause = cause.getCause();
}
if (cause instanceof InvocationTargetException) {
cause = cause.getCause();
}
if (cause instanceof WicketResourceGoneException
|| cause instanceof ResourceGoneException) {
return new renderpagerequesthandler(new
ResourceGonePage((WicketResourceGoneException)cause));
}
if (cause instanceof ResourceNotFoundException) {
return new renderpagerequesthandler(new
NotFoundPage((ResourceNotFoundException)cause));
}
});
-igor
On Mon, Nov 14, 2011 at 3:34 PM, Nelson Segura nsegu...@gmail.com wrote:
Hello,
I am starting to migrate from 1.4 to 1.5.
I am having problems trying to figure out exactly what is the best way
to do the following.
I have some custom exception and some custom pages for when the code
throws those exception. In 1.4 this seemed trivial. For example
..
public class MyRequestLifecycle extends WebRequestCycle {
public MyRequestLifecycle(org.apache.wicket.protocol.http.WebApplication
application,
WebRequest request,
Response response) {
super(application, request, response);
}
@Override
public Page onRuntimeException(Page page, RuntimeException e) {
Throwable cause = e;
if (cause instanceof WicketRuntimeException) {
cause = cause.getCause();
}
if (cause instanceof InvocationTargetException) {
cause = cause.getCause();
}
if (cause instanceof WicketResourceGoneException
|| cause instanceof ResourceGoneException) {
return new ResourceGonePage((WicketResourceGoneException)cause);
}
if (cause instanceof ResourceNotFoundException) {
return new NotFoundPage((ResourceNotFoundException)cause);
}
return super.onRuntimeException(page, e);
}
}
But I can't figure out a clean / easy way to do this in 1.5. I seems
that I need to write a lot of code to accomplish this.
I am looking at the following links:
https://cwiki.apache.org/WICKET/migration-to-wicket-15.html
https://cwiki.apache.org/WICKET/requestcycle-in-wicket-15.html
Problems are:
- Which class should I be extend or implementing.
AbstractRequestCycleListener? IExceptionMapper? IRequestHandler?
- How do I get access to the current page?
If I return a IRequestHandler, how do I create one. Do I need to
create one? Can I use the current one? do I need to worry if this is
part of an AjaxRequest? I have looked at code in
AbstractRequestCycleListener, SystemMapper, CompoundRequestMapper,
DefaultExceptionMapper, etc. It all seems too low level compared to
other Wicket APIs, that makes me think I am missing something.
What should I do?
-Nelson
-
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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Exception Handling in 1.5
Hello,
I am starting to migrate from 1.4 to 1.5.
I am having problems trying to figure out exactly what is the best way
to do the following.
I have some custom exception and some custom pages for when the code
throws those exception. In 1.4 this seemed trivial. For example
..
public class MyRequestLifecycle extends WebRequestCycle {
public MyRequestLifecycle(org.apache.wicket.protocol.http.WebApplication
application,
WebRequest request,
Response response) {
super(application, request, response);
}
@Override
public Page onRuntimeException(Page page, RuntimeException e) {
Throwable cause = e;
if (cause instanceof WicketRuntimeException) {
cause = cause.getCause();
}
if (cause instanceof InvocationTargetException) {
cause = cause.getCause();
}
if (cause instanceof WicketResourceGoneException
|| cause instanceof ResourceGoneException) {
return new ResourceGonePage((WicketResourceGoneException)cause);
}
if (cause instanceof ResourceNotFoundException) {
return new NotFoundPage((ResourceNotFoundException)cause);
}
return super.onRuntimeException(page, e);
}
}
But I can't figure out a clean / easy way to do this in 1.5. I seems
that I need to write a lot of code to accomplish this.
I am looking at the following links:
https://cwiki.apache.org/WICKET/migration-to-wicket-15.html
https://cwiki.apache.org/WICKET/requestcycle-in-wicket-15.html
Problems are:
- Which class should I be extend or implementing.
AbstractRequestCycleListener? IExceptionMapper? IRequestHandler?
- How do I get access to the current page?
If I return a IRequestHandler, how do I create one. Do I need to
create one? Can I use the current one? do I need to worry if this is
part of an AjaxRequest? I have looked at code in
AbstractRequestCycleListener, SystemMapper, CompoundRequestMapper,
DefaultExceptionMapper, etc. It all seems too low level compared to
other Wicket APIs, that makes me think I am missing something.
What should I do?
-Nelson
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Exception Handling in 1.5
application.getrequestcyclelisteners().add(new abstractrequestcyclelistener() {
irequsthandler onexception(e) {
Throwable cause = e;
if (cause instanceof WicketRuntimeException) {
cause = cause.getCause();
}
if (cause instanceof InvocationTargetException) {
cause = cause.getCause();
}
if (cause instanceof WicketResourceGoneException
|| cause instanceof ResourceGoneException) {
return new renderpagerequesthandler(new
ResourceGonePage((WicketResourceGoneException)cause));
}
if (cause instanceof ResourceNotFoundException) {
return new renderpagerequesthandler(new
NotFoundPage((ResourceNotFoundException)cause));
}
});
-igor
On Mon, Nov 14, 2011 at 3:34 PM, Nelson Segura nsegu...@gmail.com wrote:
Hello,
I am starting to migrate from 1.4 to 1.5.
I am having problems trying to figure out exactly what is the best way
to do the following.
I have some custom exception and some custom pages for when the code
throws those exception. In 1.4 this seemed trivial. For example
..
public class MyRequestLifecycle extends WebRequestCycle {
public MyRequestLifecycle(org.apache.wicket.protocol.http.WebApplication
application,
WebRequest request,
Response response) {
super(application, request, response);
}
@Override
public Page onRuntimeException(Page page, RuntimeException e) {
Throwable cause = e;
if (cause instanceof WicketRuntimeException) {
cause = cause.getCause();
}
if (cause instanceof InvocationTargetException) {
cause = cause.getCause();
}
if (cause instanceof WicketResourceGoneException
|| cause instanceof ResourceGoneException) {
return new ResourceGonePage((WicketResourceGoneException)cause);
}
if (cause instanceof ResourceNotFoundException) {
return new NotFoundPage((ResourceNotFoundException)cause);
}
return super.onRuntimeException(page, e);
}
}
But I can't figure out a clean / easy way to do this in 1.5. I seems
that I need to write a lot of code to accomplish this.
I am looking at the following links:
https://cwiki.apache.org/WICKET/migration-to-wicket-15.html
https://cwiki.apache.org/WICKET/requestcycle-in-wicket-15.html
Problems are:
- Which class should I be extend or implementing.
AbstractRequestCycleListener? IExceptionMapper? IRequestHandler?
- How do I get access to the current page?
If I return a IRequestHandler, how do I create one. Do I need to
create one? Can I use the current one? do I need to worry if this is
part of an AjaxRequest? I have looked at code in
AbstractRequestCycleListener, SystemMapper, CompoundRequestMapper,
DefaultExceptionMapper, etc. It all seems too low level compared to
other Wicket APIs, that makes me think I am missing something.
What should I do?
-Nelson
-
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
[Migration 1.5]: exception handling in request cycle
Hi,
I'm trying to plug into the new request cycle processor of 1.5-RC5.1. I am
following the instructions in the wiki page, but I seem to have run into some
out-of-date info. So, according to:
https://cwiki.apache.org/WICKET/migration-to-wicket-15.html#MigrationtoWicket1.5-RequestCycle:
1) I must create a class implementing IRequestCycleListener
2) I must bind my listener during application init() with
getRequestCycleListeners().add(...);
My problem is that previously when we extended the WebRequestCycle, we would
preserve the default exception handling by using:
@Override
public Page onRuntimeException(Page page, RuntimeException e) {
return super.onRuntimeException(page, e);
}
Now, the wiki page claims that in my listener I can:
public void onException(Exception ex) { /*do nothing*/} However, the new
listener interface forces you to return a handler (IRequestHandler), it does
not
return void as claimed in the wiki. So what do I do to return something that
will tell Wicket to proceed with its default Exception handling? The actual
signature is:
public IRequestHandler onException(RequestCycle cycle, Exception ex) {
// what do I return in order not to interfere?
}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: [Migration 1.5]: exception handling in request cycle
See the last point at
https://cwiki.apache.org/confluence/display/WICKET/RequestCycle+in+Wicket+1.5
Please update the wiki page after this.
The Migration wiki page has a Note point at the top that there is a
Wiki label at the bottom clicking on which will show you all pages
with info about 1.5.
It seems this note is not quite visible to the users. Ideas how to
improve that is welcome!
On Tue, Jul 19, 2011 at 12:35 PM, Alexandros Karypidis
akary...@yahoo.gr wrote:
Hi,
I'm trying to plug into the new request cycle processor of 1.5-RC5.1. I am
following the instructions in the wiki page, but I seem to have run into some
out-of-date info. So, according to:
https://cwiki.apache.org/WICKET/migration-to-wicket-15.html#MigrationtoWicket1.5-RequestCycle:
1) I must create a class implementing IRequestCycleListener
2) I must bind my listener during application init() with
getRequestCycleListeners().add(...);
My problem is that previously when we extended the WebRequestCycle, we would
preserve the default exception handling by using:
@Override
public Page onRuntimeException(Page page, RuntimeException e) {
return super.onRuntimeException(page, e);
}
Now, the wiki page claims that in my listener I can:
public void onException(Exception ex) { /*do nothing*/} However, the new
listener interface forces you to return a handler (IRequestHandler), it does
not
return void as claimed in the wiki. So what do I do to return something that
will tell Wicket to proceed with its default Exception handling? The actual
signature is:
public IRequestHandler onException(RequestCycle cycle, Exception ex) {
// what do I return in order not to interfere?
}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: [Migration 1.5]: exception handling in request cycle
Ok, thx.
In terms of improving the wiki, I guess my source of confusion was that I was
reading:
https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+1.5#MigrationtoWicket1.5-RequestCycle
I fixed the signature of onException(...) and also added some comments in the
sample request listener implementation (indicating that you may return null).
Finally, I added a link to the page you directed me to in the Exception
Handling section immediately afterwards which only mentioned the exception
mapper. This should help one find that the mapper is used only in case all of
the listeners return null.
Alex.
- Original Message
From: Martin Grigorov mgrigo...@apache.org
To: users@wicket.apache.org
Sent: Tue, July 19, 2011 12:47:54 PM
Subject: Re: [Migration 1.5]: exception handling in request cycle
See the last point at
https://cwiki.apache.org/confluence/display/WICKET/RequestCycle+in+Wicket+1.5
Please update the wiki page after this.
The Migration wiki page has a Note point at the top that there is a
Wiki label at the bottom clicking on which will show you all pages
with info about 1.5.
It seems this note is not quite visible to the users. Ideas how to
improve that is welcome!
On Tue, Jul 19, 2011 at 12:35 PM, Alexandros Karypidis
akary...@yahoo.gr wrote:
Hi,
I'm trying to plug into the new request cycle processor of 1.5-RC5.1. I am
following the instructions in the wiki page, but I seem to have run into some
out-of-date info. So, according to:
https://cwiki.apache.org/WICKET/migration-to-wicket-15.html#MigrationtoWicket1.5-RequestCycle:
:
1) I must create a class implementing IRequestCycleListener
2) I must bind my listener during application init() with
getRequestCycleListeners().add(...);
My problem is that previously when we extended the WebRequestCycle, we would
preserve the default exception handling by using:
@Override
public Page onRuntimeException(Page page, RuntimeException e) {
return super.onRuntimeException(page, e);
}
Now, the wiki page claims that in my listener I can:
public void onException(Exception ex) { /*do nothing*/} However, the new
listener interface forces you to return a handler (IRequestHandler), it does
not
return void as claimed in the wiki. So what do I do to return something that
will tell Wicket to proceed with its default Exception handling? The actual
signature is:
public IRequestHandler onException(RequestCycle cycle, Exception ex) {
// what do I return in order not to interfere?
}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.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
Exception handling for components inside a page
I have a Wicket page which is a dashboard composed of a number of panels. The actual panels are only known in runtime and are added to a RepeatingView. That's because I have a modular application, and each module can contribute panels to the dashboard. The modularity issue is well solved and working as expected. My problem is when any of the panels throws an Exception. In that case Wicket directs me to my error page. I would like to be able to handle the exception on the panel level and just replace the panel area with some error notification, but the other panels would still be shown. That way I have to find out what's going on with that panel, but the users can still use the rest of the dashboard. Is there any hook point where I could include a handler? I can control the instantiation of the panel, but I would still have to handle any exception during the render phase, but I can't figure out where I could do this. Best Regards -- Rui Fernando Hayashi - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Exception handling for components inside a page
no, there isnt. exceptions that occur during render time are very hard to recover from. what you can do is place every panel into an iframe. -igor On Fri, Oct 1, 2010 at 7:14 AM, Rui Fernando Hayashi rui.haya...@tecsinapse.com.br wrote: I have a Wicket page which is a dashboard composed of a number of panels. The actual panels are only known in runtime and are added to a RepeatingView. That's because I have a modular application, and each module can contribute panels to the dashboard. The modularity issue is well solved and working as expected. My problem is when any of the panels throws an Exception. In that case Wicket directs me to my error page. I would like to be able to handle the exception on the panel level and just replace the panel area with some error notification, but the other panels would still be shown. That way I have to find out what's going on with that panel, but the users can still use the rest of the dashboard. Is there any hook point where I could include a handler? I can control the instantiation of the panel, but I would still have to handle any exception during the render phase, but I can't figure out where I could do this. Best Regards -- Rui Fernando Hayashi - 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: EXception handling in Wicket
arunarapole wrote: Thank you for replay i am very glad you have sent me the sample code thank you so much My problem is i have to handle SQLException and only message to be display in hidden field same webpage do u have any idea regarding this Aruna It depends. Is your exception thrown in an ajax call or a form submit? In your WebRequestCycle.onRuntimeException you have two parameters: page on which exception was thrown and which exception was thrown. If your runtime exception was SQLException then you can access any element on your page and set any value to it. Next you can update an element on page if it's AJAX or show this page again by returning updated page. You can get your ajax target this way: (AjaxRequestTarget)RequestCycle.get().getRequestTarget(). -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/EXception-handling-in-Wicket-tp2340439p2399426.html Sent from the Wicket - User 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: EXception handling in Wicket
Antoine van Wel wrote: I think you should prevent that SQLException from happening in the first place by validating the form input. Then use a FeedbackPanel to display suitable error messages. Just google for example code with forms, it's basic stuff. Otherwise, create a FeedbackPanel on your page, put a try .. catch block around your sql methods and in case of an exception, write to the FeedbackPanel using error(your message) I agree with you, catching Runtime exceptions in WebRequestCycle should not be a part of normal workflow. I use this thing only to display critical failures information. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/EXception-handling-in-Wicket-tp2340439p2399427.html Sent from the Wicket - User 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: EXception handling in Wicket
I think you should prevent that SQLException from happening in the first place by validating the form input. Then use a FeedbackPanel to display suitable error messages. Just google for example code with forms, it's basic stuff. Otherwise, create a FeedbackPanel on your page, put a try .. catch block around your sql methods and in case of an exception, write to the FeedbackPanel using error(your message) Antoine On Fri, Aug 27, 2010 at 3:02 PM, arunarapole arunakumm...@gmail.com wrote: Thank you for replay i am very glad you have sent me the sample code thank you so much My problem is i have to handle SQLException and only message to be display in hidden field same webpage do u have any idea regarding this Aruna On Thu, Aug 26, 2010 at 10:14 PM, Nitnatsnok [via Apache Wicket] ml-node+2340562-650873628-136...@n4.nabble.comml-node%2b2340562-650873628-136...@n4.nabble.com ml-node%2b2340562-650873628-136...@n4.nabble.comml-node%252b2340562-650873628-136...@n4.nabble.com wrote: Oh, also I set not to show Error Page on exception in WebApplication: getExceptionSettings().setUnexpectedExceptionDisplay(IExceptionSettings.SHOW_NO_EXCEPTION_PAGE); -- View message @ http://apache-wicket.1842946.n4.nabble.com/EXception-handling-in-Wicket-tp2340439p2340562.html To unsubscribe from EXception handling in Wicket, click here http://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_codenode=2340439code=YXJ1bmFrdW1tYXJpQGdtYWlsLmNvbXwyMzQwNDM5fC00Njg4NjYxODg= . -- Regards Aruna.R 404-988-5562 -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/EXception-handling-in-Wicket-tp2340439p2341035.html Sent from the Wicket - User mailing list archive at Nabble.com.
Re: EXception handling in Wicket
Thank you for replay i am very glad you have sent me the sample code thank you so much My problem is i have to handle SQLException and only message to be display in hidden field same webpage do u have any idea regarding this Aruna On Thu, Aug 26, 2010 at 10:14 PM, Nitnatsnok [via Apache Wicket] ml-node+2340562-650873628-136...@n4.nabble.comml-node%2b2340562-650873628-136...@n4.nabble.com wrote: Oh, also I set not to show Error Page on exception in WebApplication: getExceptionSettings().setUnexpectedExceptionDisplay(IExceptionSettings.SHOW_NO_EXCEPTION_PAGE); -- View message @ http://apache-wicket.1842946.n4.nabble.com/EXception-handling-in-Wicket-tp2340439p2340562.html To unsubscribe from EXception handling in Wicket, click herehttp://apache-wicket.1842946.n4.nabble.com/template/TplServlet.jtp?tpl=unsubscribe_by_codenode=2340439code=YXJ1bmFrdW1tYXJpQGdtYWlsLmNvbXwyMzQwNDM5fC00Njg4NjYxODg=. -- Regards Aruna.R 404-988-5562 -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/EXception-handling-in-Wicket-tp2340439p2341035.html Sent from the Wicket - User mailing list archive at Nabble.com.
EXception handling in Wicket
Hi How to display exception message in hidden field or on pop up window or feedback panel or in any wicket component in the same page where i am entering data. If any one does this please send me sample code or idea please do this i am very new to the wicket frame work. please help out me any one Thank you Aruna -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/EXception-handling-in-Wicket-tp2340439p2340439.html Sent from the Wicket - User 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: EXception handling in Wicket
Hi, I don't know if it is a proper way but this is how I did it.
1. Extended WebRequestCycle
@Override
public Page onRuntimeException(Page page, RuntimeException e) {
// if error was during application running e.g. when Home page was
loaded and if it was an ajax request that caused problem
if (page instanceof Home RequestCycle.get().getRequestTarget()
instanceof AjaxRequestTarget) {
// On my Home page there is a js ModalWindow into which I place
the error text
ModalWindow errorPage = (ModalWindow)page.get(modalErrorPage);
final ResourceModel message = new
ResourceModel(gorillaUrlError);
errorPage.setContent( ... );
errorPage.show((AjaxRequestTarget)RequestCycle.get().getRequestTarget());
}
return null;
2. Extended WebRequestCycleProcessor to comment out placing 500 error code
into Ajax response.
@Override
public void respond(RuntimeException e, RequestCycle requestCycle)
{
// If application doesn't want debug info showing up for users
final Application application = Application.get();
final IExceptionSettings settings =
application.getExceptionSettings();
final Page responsePage = requestCycle.getResponsePage();
Page override = onRuntimeException(responsePage, e);
if (override != null)
{
throw new RestartResponseException(override);
}
else if (e instanceof AuthorizationException)
{
// are authorization exceptions always thrown before the real
// render?
// else we need to make a page (see below) or set it hard to a
// redirect.
Class? extends Page accessDeniedPageClass =
application.getApplicationSettings()
.getAccessDeniedPage();
throw new
RestartResponseAtInterceptPageException(accessDeniedPageClass);
}
else if (e instanceof PageExpiredException)
{
Class? extends Page pageExpiredErrorPageClass =
application.getApplicationSettings()
.getPageExpiredErrorPage();
boolean mounted = isPageMounted(pageExpiredErrorPageClass);
RequestCycle.get().setRedirect(mounted);
throw new RestartResponseException(pageExpiredErrorPageClass);
}
else if (settings.getUnexpectedExceptionDisplay() !=
IExceptionSettings.SHOW_NO_EXCEPTION_PAGE)
{
// we do not want to redirect - we want to inline the error
output
// and preserve the url so when the refresh button is pressed we
// rerun the code that caused the error
// However we don't what to do this in a situation where we are
in portlet mode
if (!RequestContext.get().isPortletRequest())
{
requestCycle.setRedirect(false);
}
// figure out which error page to show
Class? extends Page internalErrorPageClass =
application.getApplicationSettings()
.getInternalErrorPage();
Class? extends Page responseClass = responsePage != null ?
responsePage.getClass()
: null;
if (responseClass != internalErrorPageClass
settings.getUnexpectedExceptionDisplay() ==
IExceptionSettings.SHOW_INTERNAL_ERROR_PAGE)
{
throw new RestartResponseException(internalErrorPageClass);
}
else if (responseClass != ExceptionErrorPage.class)
{
// Show full details
throw new RestartResponseException(new ExceptionErrorPage(e,
responsePage));
}
else
{
// give up while we're ahead!
throw new WicketRuntimeException(Internal Error: Could not
render error page +
internalErrorPageClass, e);
}
}
else if (requestCycle.getResponse() instanceof WebResponse)
{
// commented out so that error code is not set to header
// it was set in case of runtime Java exception and
SHOW_NO_EXCEPTION_PAGE option of application
//
((WebResponse)requestCycle.getResponse()).getHttpServletResponse().setStatus(
//HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
}
}
3. Overridden 2 methods in WebApplication
public RequestCycle newRequestCycle(Request request, Response response) {
protected IRequestCycleProcessor newRequestCycleProcessor() {
That's it.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/EXception-handling-in-Wicket-tp2340439p2340560.html
Sent from the Wicket - User 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: EXception handling in Wicket
Oh, also I set not to show Error Page on exception in WebApplication: getExceptionSettings().setUnexpectedExceptionDisplay(IExceptionSettings.SHOW_NO_EXCEPTION_PAGE); -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/EXception-handling-in-Wicket-tp2340439p2340562.html Sent from the Wicket - User 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
Exception handling
Hi there, I'd like to find out how the development mechanism of exception handling works. It displays stacktrace from exception thrown, so it means it has access to the Exception object. I would like to implement similar feature, to display at least the message from the exception to the end user. Could you tell me how to do it or point the name of class shown where the exception is thrown in development mode? BTW. I know how to set internal exception page :) Regards, Wojtek - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Exception handling
In your application:
@Override
public RequestCycle newRequestCycle(Request request, Response response)
{
return new WebRequestCycle(this, (WebRequest) request, response) {
@Override
public Page onRuntimeException(Page page, RuntimeException e) {
return super.onRuntimeException(page, e);
}
};
}
--
Jeremy Thomerson
http://www.wickettraining.com
2009/11/15 Wojtek zabia...@gmail.com
Hi there,
I'd like to find out how the development mechanism of exception handling
works.
It displays stacktrace from exception thrown, so it means it has access to
the Exception object.
I would like to implement similar feature, to display at least the message
from the exception to the end user.
Could you tell me how to do it or point the name of class shown where the
exception is thrown in development mode?
BTW. I know how to set internal exception page :)
Regards,
Wojtek
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Exception handling
That's exactly what I need. Thanks a lot.
Regards,
Wojtek
Jeremy Thomerson pisze:
In your application:
@Override
public RequestCycle newRequestCycle(Request request, Response response)
{
return new WebRequestCycle(this, (WebRequest) request, response) {
@Override
public Page onRuntimeException(Page page, RuntimeException e) {
return super.onRuntimeException(page, e);
}
};
}
--
Jeremy Thomerson
http://www.wickettraining.com
2009/11/15 Wojtek zabia...@gmail.com
Hi there,
I'd like to find out how the development mechanism of exception handling
works.
It displays stacktrace from exception thrown, so it means it has access to
the Exception object.
I would like to implement similar feature, to display at least the message
from the exception to the end user.
Could you tell me how to do it or point the name of class shown where the
exception is thrown in development mode?
BTW. I know how to set internal exception page :)
Regards,
Wojtek
-
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
exception handling for session dependent URLs
I recently came across a link to one of my projects where a user linked to a session dependent URL such as /?wicket:interface=:0::IBehaviorListener:2:3 when clicking on that URL, a PageExpiredException gets thrown and a redirect to the SessionExpiredPage takes place. So far so good - that's the way it should be. However this works only for the first request (as long as the user doesn't have a session). If the user has a session and clicks on that link different exceptions might get thrown. with the URL mentioned above I've seen either a IllegalStateException (when it couldn't find a IBehaviorListener with the corresponding ID) or a ClassCastException (when it tried to cast a HeaderContributor to an IBehaviorListener in BehaviorRequestTarget). I must admit I didn't look into the code that thoroughly as I wanted to ask you first how you go about this problem (or it may be already fixed in 1.3.6/1.4 - I'm using 1.3.5). I thinks accidentally pasting session dependent URLs in blogs etc. shouldn't result in server errors ... would it be save to throw e.g. a PageExpiredException instead of IllegalStateExceptions? Michael - Michael Sparer http://techblog.molindo.at -- View this message in context: http://www.nabble.com/exception-handling-for-session-dependent-URLs-tp22037821p22037821.html Sent from the Wicket - User 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: exception handling for session dependent URLs
please create a jira issue. -igor On Mon, Feb 16, 2009 at 6:00 AM, Michael Sparer michael.spa...@gmx.at wrote: I recently came across a link to one of my projects where a user linked to a session dependent URL such as /?wicket:interface=:0::IBehaviorListener:2:3 when clicking on that URL, a PageExpiredException gets thrown and a redirect to the SessionExpiredPage takes place. So far so good - that's the way it should be. However this works only for the first request (as long as the user doesn't have a session). If the user has a session and clicks on that link different exceptions might get thrown. with the URL mentioned above I've seen either a IllegalStateException (when it couldn't find a IBehaviorListener with the corresponding ID) or a ClassCastException (when it tried to cast a HeaderContributor to an IBehaviorListener in BehaviorRequestTarget). I must admit I didn't look into the code that thoroughly as I wanted to ask you first how you go about this problem (or it may be already fixed in 1.3.6/1.4 - I'm using 1.3.5). I thinks accidentally pasting session dependent URLs in blogs etc. shouldn't result in server errors ... would it be save to throw e.g. a PageExpiredException instead of IllegalStateExceptions? Michael - Michael Sparer http://techblog.molindo.at -- View this message in context: http://www.nabble.com/exception-handling-for-session-dependent-URLs-tp22037821p22037821.html Sent from the Wicket - User 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: exception handling for session dependent URLs
aye aye captain :-) https://issues.apache.org/jira/browse/WICKET-2107 igor.vaynberg wrote: please create a jira issue. -igor On Mon, Feb 16, 2009 at 6:00 AM, Michael Sparer michael.spa...@gmx.at wrote: I recently came across a link to one of my projects where a user linked to a session dependent URL such as /?wicket:interface=:0::IBehaviorListener:2:3 when clicking on that URL, a PageExpiredException gets thrown and a redirect to the SessionExpiredPage takes place. So far so good - that's the way it should be. However this works only for the first request (as long as the user doesn't have a session). If the user has a session and clicks on that link different exceptions might get thrown. with the URL mentioned above I've seen either a IllegalStateException (when it couldn't find a IBehaviorListener with the corresponding ID) or a ClassCastException (when it tried to cast a HeaderContributor to an IBehaviorListener in BehaviorRequestTarget). I must admit I didn't look into the code that thoroughly as I wanted to ask you first how you go about this problem (or it may be already fixed in 1.3.6/1.4 - I'm using 1.3.5). I thinks accidentally pasting session dependent URLs in blogs etc. shouldn't result in server errors ... would it be save to throw e.g. a PageExpiredException instead of IllegalStateExceptions? Michael - Michael Sparer http://techblog.molindo.at -- View this message in context: http://www.nabble.com/exception-handling-for-session-dependent-URLs-tp22037821p22037821.html Sent from the Wicket - User 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 - Michael Sparer http://techblog.molindo.at -- View this message in context: http://www.nabble.com/exception-handling-for-session-dependent-URLs-tp22037821p22042612.html Sent from the Wicket - User 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: exception handling for session dependent URLs
i think this might have to wait until 1.5. we definetely cannot change this for 1.3.6 because it will change existing behavior too much. and since 1.4 is already in the RC i would rather not change it there either. since we will be rewriting all url handling in 1.5 anyways it will be a good time to implement this. -igor On Mon, Feb 16, 2009 at 10:09 AM, Michael Sparer michael.spa...@gmx.at wrote: aye aye captain :-) https://issues.apache.org/jira/browse/WICKET-2107 igor.vaynberg wrote: please create a jira issue. -igor On Mon, Feb 16, 2009 at 6:00 AM, Michael Sparer michael.spa...@gmx.at wrote: I recently came across a link to one of my projects where a user linked to a session dependent URL such as /?wicket:interface=:0::IBehaviorListener:2:3 when clicking on that URL, a PageExpiredException gets thrown and a redirect to the SessionExpiredPage takes place. So far so good - that's the way it should be. However this works only for the first request (as long as the user doesn't have a session). If the user has a session and clicks on that link different exceptions might get thrown. with the URL mentioned above I've seen either a IllegalStateException (when it couldn't find a IBehaviorListener with the corresponding ID) or a ClassCastException (when it tried to cast a HeaderContributor to an IBehaviorListener in BehaviorRequestTarget). I must admit I didn't look into the code that thoroughly as I wanted to ask you first how you go about this problem (or it may be already fixed in 1.3.6/1.4 - I'm using 1.3.5). I thinks accidentally pasting session dependent URLs in blogs etc. shouldn't result in server errors ... would it be save to throw e.g. a PageExpiredException instead of IllegalStateExceptions? Michael - Michael Sparer http://techblog.molindo.at -- View this message in context: http://www.nabble.com/exception-handling-for-session-dependent-URLs-tp22037821p22037821.html Sent from the Wicket - User 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 - Michael Sparer http://techblog.molindo.at -- View this message in context: http://www.nabble.com/exception-handling-for-session-dependent-URLs-tp22037821p22042612.html Sent from the Wicket - User 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
Custom Domain Exception Handling
All, I am working with a domain where the POJOs have a method that checks there values, and throws an exception with the error message if there is a problem with one of there property values. I am using panels to model these objects, is there something I can do to utilize this behavior when a form submits. So that the form submit, and persisting of the models properties will make the panel aware that there is an error. Im not looking for a full explanation of an implementation, just a quick explanation of how the model objects properties get persisted. Thanks! Justin -- View this message in context: http://www.nabble.com/Custom-Domain-Exception-Handling-tp21851678p21851678.html Sent from the Wicket - User 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: Custom Domain Exception Handling
class myform extends form {
public void process() {
try {
super.process();
} catch (basedomainexception e) {
error(e.getusermessage());
}
}
}
-igor
On Thu, Feb 5, 2009 at 5:49 AM, walnutmon justin.m.boy...@gmail.com wrote:
All,
I am working with a domain where the POJOs have a method that checks there
values, and throws an exception with the error message if there is a problem
with one of there property values. I am using panels to model these
objects, is there something I can do to utilize this behavior when a form
submits. So that the form submit, and persisting of the models properties
will make the panel aware that there is an error.
Im not looking for a full explanation of an implementation, just a quick
explanation of how the model objects properties get persisted.
Thanks!
Justin
--
View this message in context:
http://www.nabble.com/Custom-Domain-Exception-Handling-tp21851678p21851678.html
Sent from the Wicket - User 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: How to make a popup page for exception handling?
Hi my wicket friends,
There is fast way to make the popup for exception handling:
try {
...
}
catch (Exception e){
target.appendJavascript(String.format(alert('%s'),
e));
}
and AjaxSubmitLink is used.
-Mo Wu
Michael O'Cleirigh wrote:
Hi Mo,
I tried them, I can generate the modal Window. but the AjaxLink is not
submit
link for a form. I need to show the error message only if there is form
processing error.
Should I use AjaxSubmitLink instead? or do you have some examples similar
to
this condition?
If the alerts you want to show are tied to the existence of form
processing errors then prehaps you should subclass FeedbackPanel to add
in a javascript popup alert in addition to/replacing the standard
behavior of displaying the form errors in an unordered list?
Or you could create a panel consisting of the modal window and the
activation link but tied to the existence of feedback messages. If
there are zero feedback messages (the form not submitted yet case) you
can have the panel invisible to start with (i.e. the link would not be
there or say something like 'No Errors'). When there are errors present
the link would be visible (or say something link 'There are X errors')
clicking the link would show the modal window with the errors.
Normally feedback messages are expected to be consumed by the feedback
panels during the rendering phase so they are cleared at the end of the
form submission request; you might have to cache it somewhere so that
the modal window will have the data available it since it populates
itself via an ajax update after the form submitting request that
generated the errors has already finished.
Regards,
Mike
cheers, :)
Mo
Newgro wrote:
Fkleinko wrote:
To show the ModalWindow you need an AjaxRequestTarget.
where do you get that from?
AjaxLink theLinkThatWillShowTheModalWindowIfItsClicked = new
AjaxLink(...)
{
public void onClick(AjaxRequestTarget target) {
myModalWindow.show(target);
}
}
Please check the examples i gave you. It's all there.
Cheers
Per
--
View this message in context:
http://www.nabble.com/How-to-make-a-popup-page-for-exception-handling--tp21588129p21709550.html
Sent from the Wicket - User 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: How to make a popup page for exception handling?
what is the type of the errorWindow? Is the errorWindow a new page or a part
of the existing page?
Best regards,
Mo
Newgro wrote:
I know how to show the exception in a feedback panel. But how to make the
popup dependent on the results of submission
You could add the errorWindow to your page and in your catch you can
show it. But it's only working with ajax.
add errorWindow to markup and in class.
try {
exceptionalCode();
} catch (TheExpectedException e) {
errorWindow.setModel(new Model(e));
errorWindow.show();
}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
View this message in context:
http://www.nabble.com/How-to-make-a-popup-page-for-exception-handling--tp21588129p21600597.html
Sent from the Wicket - User 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: How to make a popup page for exception handling?
Its a ModalWindow. Sorry for being unclear here. Check this for usage http://www.wicket-library.com/wicket-examples/ajax/modal-window.1 http://www.wicket-library.com/wicket-examples/ajax/modal-window.1 There you can find the sources (right upper corner) on howto use it with page in it and so on. HTH Per -- View this message in context: http://www.nabble.com/How-to-make-a-popup-page-for-exception-handling--tp21588129p21601120.html Sent from the Wicket - User 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: How to make a popup page for exception handling?
To show the ModalWindow you need an AjaxRequestTarget. where do you get that from? Newgro wrote: Its a ModalWindow. Sorry for being unclear here. Check this for usage http://www.wicket-library.com/wicket-examples/ajax/modal-window.1 http://www.wicket-library.com/wicket-examples/ajax/modal-window.1 There you can find the sources (right upper corner) on howto use it with page in it and so on. HTH Per -- View this message in context: http://www.nabble.com/How-to-make-a-popup-page-for-exception-handling--tp21588129p21604441.html Sent from the Wicket - User 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: How to make a popup page for exception handling?
Fkleinko wrote:
To show the ModalWindow you need an AjaxRequestTarget.
where do you get that from?
AjaxLink theLinkThatWillShowTheModalWindowIfItsClicked = new AjaxLink(...) {
public void onClick(AjaxRequestTarget target) {
myModalWindow.show(target);
}
}
Please check the examples i gave you. It's all there.
Cheers
Per
--
View this message in context:
http://www.nabble.com/How-to-make-a-popup-page-for-exception-handling--tp21588129p21604547.html
Sent from the Wicket - User 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: How to make a popup page for exception handling?
I tried them, I can generate the modal Window. but the AjaxLink is not submit
link for a form. I need to show the error message only if there is form
processing error.
Should I use AjaxSubmitLink instead? or do you have some examples similar to
this condition?
cheers, :)
Mo
Newgro wrote:
Fkleinko wrote:
To show the ModalWindow you need an AjaxRequestTarget.
where do you get that from?
AjaxLink theLinkThatWillShowTheModalWindowIfItsClicked = new AjaxLink(...)
{
public void onClick(AjaxRequestTarget target) {
myModalWindow.show(target);
}
}
Please check the examples i gave you. It's all there.
Cheers
Per
--
View this message in context:
http://www.nabble.com/How-to-make-a-popup-page-for-exception-handling--tp21588129p21605575.html
Sent from the Wicket - User 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: How to make a popup page for exception handling?
Hi Mo,
I tried them, I can generate the modal Window. but the AjaxLink is not submit
link for a form. I need to show the error message only if there is form
processing error.
Should I use AjaxSubmitLink instead? or do you have some examples similar to
this condition?
If the alerts you want to show are tied to the existence of form
processing errors then prehaps you should subclass FeedbackPanel to add
in a javascript popup alert in addition to/replacing the standard
behavior of displaying the form errors in an unordered list?
Or you could create a panel consisting of the modal window and the
activation link but tied to the existence of feedback messages. If
there are zero feedback messages (the form not submitted yet case) you
can have the panel invisible to start with (i.e. the link would not be
there or say something like 'No Errors'). When there are errors present
the link would be visible (or say something link 'There are X errors')
clicking the link would show the modal window with the errors.
Normally feedback messages are expected to be consumed by the feedback
panels during the rendering phase so they are cleared at the end of the
form submission request; you might have to cache it somewhere so that
the modal window will have the data available it since it populates
itself via an ajax update after the form submitting request that
generated the errors has already finished.
Regards,
Mike
cheers, :)
Mo
Newgro wrote:
Fkleinko wrote:
To show the ModalWindow you need an AjaxRequestTarget.
where do you get that from?
AjaxLink theLinkThatWillShowTheModalWindowIfItsClicked = new AjaxLink(...)
{
public void onClick(AjaxRequestTarget target) {
myModalWindow.show(target);
}
}
Please check the examples i gave you. It's all there.
Cheers
Per
How to make a popup page for exception handling?
Dear experts, I have one feature to be implemented, but I dont know how to do that: I have one page, there is a form need to be submitted. after submitted, 1. If the results is correct, then the same page is returned. 2. if there are some exceptions, then a popup need to be shown up and it should also show the errorMessage. I know how to show the exception in a feedback panel. But how to make the popup dependent on the results of submission. Thanks for help! Best regards, Mo -- View this message in context: http://www.nabble.com/How-to-make-a-popup-page-for-exception-handling--tp21588129p21588129.html Sent from the Wicket - User 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: How to make a popup page for exception handling?
I know how to show the exception in a feedback panel. But how to make the
popup dependent on the results of submission
You could add the errorWindow to your page and in your catch you can
show it. But it's only working with ajax.
add errorWindow to markup and in class.
try {
exceptionalCode();
} catch (TheExpectedException e) {
errorWindow.setModel(new Model(e));
errorWindow.show();
}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Global Exception Handling...
On 3/11/08, Igor Vaynberg [EMAIL PROTECTED] wrote:
The request cycle is easy enough to access anywhere, RequestCycle.get()
right?
im not a big fan of using threadlocals everywhere personally...we
guarantee certain ones, but they make unit testing, etc, a pita. i
would prefer passing the instance in.
I'm not a big fan either. Adding a parameter isn't a bad idea, then.
If a user needs more advanced search capability, I guess
they could do it themselves. Maybe the search algorithm could be put
in the RequestCycle class' onRuntimeException() method itself. Then,
all you'd have to do is override Application.newRequestCycle() and
RequestCycle.onRuntimeException() to plug in your own advanced handler
search capability. I think this sort of feature is a common enough
need that it could be built in, but that's just my opinion.
ok. this is making more sense. so we would change Page
onRuntimeException(RT e) to ExceptionHandler onRuntimeException(RT e),
and the default resolution algorithm will be what most people agree on
as the best default. on the other hand, you can just override
requestcycle.onruntimeexception(rt e) {
map
handlers=beanfactoryutils.beansoftypeincludingancestors(applicationcontext,exceptionhandler.class);
for (excpetionhandler handler:handlers.values()) {
if (handler.matches(e)) { return e.getPage(e); break; }
}
return super.onruntimeexception(e);
}
The change I was suggesting wouldn't break any existing code (unless
someone implemented IRequestCycleSettings). The signature of
RequestCycle.onRuntimeException() wouldn't change:
public Page onRuntimeException( Page page, RuntimeException e )
{
IRuntimeExceptionHandler handler = findBestExceptionHandler(e.getClass());
if(handler != null)
{
return handler.onRuntimeException(this, e);
}
return null;
}
protected IRuntimeExceptionHandler findBestExceptionHandler(Class
exceptionClass)
{
while(exceptionClass != null !exceptionClass.equals(Exception.class))
{
IRuntimeExceptionHandler handler =
getApplication().getRequestCycleSettings().getRuntimeExceptionHandler(exceptionClass);
if(handler != null)
{
return handler;
}
exceptionClass = exceptionClass.getSuperclass();
}
return null;
}
This way, if the user wants to override the search algorithm, they can
override the findBestExceptionHandler() method. And, if they haven't
registered any handlers, then this method does exactly what it used to
do (nothing). Whatever the default algorithm would be of course is up
for debate. This is just simple example (and off the top of my head,
so if it really doesn't work as is, then sorry).
our api surface area is already pretty large, makes the framework
harder to learn. so we try to keep it as small as possible, that is
not to say we do not implement new ideas/features.
Trust me, I know (about the hard to learn part)! I signed up to do a
talk on Wicket to our local Java users group (anyone in the
Cincinnati, OH area is free to join us next Monday) and it has now
turned into two talks: Introduction to Wicket and Advanced Wicket (May
2008)!
i believe most, all that i have worked on, wicket application have
their own custom subclass of webrequestcycle, so a factory wouldnt
really benefit anyone if it's only purpose is to make installing a
generic subclass easier. what you can do is create your own subclass
of webrequestcycle that has handler registration, that way users can
subclass yours instead of webrequestcycle and get the handler
functionality. you can, for example, store registered handlers in
application metadata facility.
Okay, so it's common to do your own request cycle implementation. I
didn't realize that. In Tapestry, RequestCycle wasn't something you
monkeyed around with much.
So, you're saying that I would store my exception handler registry
as metadata entries on the Application class? I would maybe store my
MapClass,IRuntimeExceptionHandler? What would the MetaDataKey be?
I just don't want to force users to subclass a custom WebApplication
class. I'd rather have the IRuntimeRequestHandlers registered with
IRequestCycleSettings (or the IExceptionSettings, maybe?).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Global Exception Handling...
On 3/11/08, James Carman [EMAIL PROTECTED] wrote:
The change I was suggesting wouldn't break any existing code (unless
someone implemented IRequestCycleSettings). The signature of
RequestCycle.onRuntimeException() wouldn't change:
public Page onRuntimeException( Page page, RuntimeException e )
{
IRuntimeExceptionHandler handler = findBestExceptionHandler(e.getClass());
if(handler != null)
{
return handler.onRuntimeException(this, e);
}
return null;
}
protected IRuntimeExceptionHandler findBestExceptionHandler(Class
exceptionClass)
{
while(exceptionClass != null !exceptionClass.equals(Exception.class))
{
IRuntimeExceptionHandler handler =
getApplication().getRequestCycleSettings().getRuntimeExceptionHandler(exceptionClass);
if(handler != null)
{
return handler;
}
exceptionClass = exceptionClass.getSuperclass();
}
return null;
}
This way, if the user wants to override the search algorithm, they can
override the findBestExceptionHandler() method. And, if they haven't
registered any handlers, then this method does exactly what it used to
do (nothing). Whatever the default algorithm would be of course is up
for debate. This is just simple example (and off the top of my head,
so if it really doesn't work as is, then sorry).
By the way, I can create a patch for this stuff if you like. I guess
the decision needs to be made about where the registry
(MapClass,IRuntimeExceptionHandler) needs to go. Does it belong in
IRequestCycleSettings or IExceptionSettings? And, do you want me to
apply it to my already existing code which splits up Settings into
multiple default implementations (which you guys said we should hold
off on for 1.4.x)?
Perhaps there could be logic in there that checks to see if the
requested Page object which caused the RuntimeException implements
IRuntimeExceptionHandler also. That way, an individual page could
override the global behavior if they wish. Just a thought.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Global Exception Handling...
On Tue, Mar 11, 2008 at 3:30 AM, James Carman [EMAIL PROTECTED] wrote: Okay, so it's common to do your own request cycle implementation. I didn't realize that. In Tapestry, RequestCycle wasn't something you monkeyed around with much. yep, its pretty common. So, you're saying that I would store my exception handler registry as metadata entries on the Application class? I would maybe store my MapClass,IRuntimeExceptionHandler? What would the MetaDataKey be? you would create your own, preferrably inner private, subclass of MetaDataKey and use that. that way no body but you can access those entries. I just don't want to force users to subclass a custom WebApplication class. thus my suggestion of using metadata I'd rather have the IRuntimeRequestHandlers registered with IRequestCycleSettings (or the IExceptionSettings, maybe?). well, another thing here is that there are two ways of setting this up. one way is to push handlers into the request cycle, another way is to have request cycle lookup the handlers from some registry. if i were using spring, as i assume you are, i would create a registry bean for the handlers that would live in spring context and collect all the beans. the request cycle would then simply lookup this registry bean and iterate over registered handlers. this is kinda why we try not to put things like this into core. implementations vary a lot based on how your architecture is setup and forcing one particular way makes code for others inelegant... -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Global Exception Handling...
On Tue, Mar 11, 2008 at 3:51 AM, James Carman [EMAIL PROTECTED] wrote: By the way, I can create a patch for this stuff if you like. I guess the decision needs to be made about where the registry (MapClass,IRuntimeExceptionHandler) needs to go. Does it belong in IRequestCycleSettings or IExceptionSettings? i think you should hold off on the patch until you have settled down on how you want to do this And, do you want me to apply it to my already existing code which splits up Settings into multiple default implementations (which you guys said we should hold off on for 1.4.x)? we havent decided if we are going to apply that patch or not, just that we cant even start thinking about it until 1.4. i would say its safer to create a patch off standard trunk. Perhaps there could be logic in there that checks to see if the requested Page object which caused the RuntimeException implements IRuntimeExceptionHandler also. That way, an individual page could override the global behavior if they wish. Just a thought. that might make sense. but you have to realize that Page is a pretty coarse scope for something like this. a lot of applications consist of few pages that only act as containers for panels that are swapped in and out, so i can have an application that is made up of one page and everything else is madeup of panels that i swap in and out in that main container page... -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Global Exception Handling...
If I'm developing a Hibernate-based application and I want to install some global StateObjectStateException handling code, what's the best way to do it? I could override Application.newRequestCycle() providing my own request cycle implementation which overrides the onRuntimeException() method. Is there a way to plug in logic which says if you see exception type X, use this handler? James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Global Exception Handling...
On Mon, Mar 10, 2008 at 7:39 PM, James Carman
[EMAIL PROTECTED] wrote:
If I'm developing a Hibernate-based application and I want to install
some global StateObjectStateException handling code, what's the best
way to do it? I could override Application.newRequestCycle()
providing my own request cycle implementation which overrides the
onRuntimeException() method. Is there a way to plug in logic which
says if you see exception type X, use this handler?
notice requestcycle.onruntimeexception() has access to the exception,
and returns a page, so
myrc.onruntimexception(runtimeexception e) {
if (e.getrootcause() instanceof hibernateexception) {
return new hibernateerrorpage(e);
}
}
-igor
James
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Global Exception Handling...
On 3/10/08, Igor Vaynberg [EMAIL PROTECTED] wrote:
On Mon, Mar 10, 2008 at 7:39 PM, James Carman
[EMAIL PROTECTED] wrote:
If I'm developing a Hibernate-based application and I want to install
some global StateObjectStateException handling code, what's the best
way to do it? I could override Application.newRequestCycle()
providing my own request cycle implementation which overrides the
onRuntimeException() method. Is there a way to plug in logic which
says if you see exception type X, use this handler?
notice requestcycle.onruntimeexception() has access to the exception,
and returns a page, so
myrc.onruntimexception(runtimeexception e) {
if (e.getrootcause() instanceof hibernateexception) {
return new hibernateerrorpage(e);
}
}
Okay, so this is the way to handle it, eh? I just wanted to make sure
there was nothing out there already for this. I may make up a
Spring-based solution that allows me to register an exception
handler for specific types of runtime exceptions. That way, my forms
don't need to know I'm using Hibernate. They can just deal with my
domain interface (a repository). Thanks for the tip!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Global Exception Handling...
On 3/10/08, James Carman [EMAIL PROTECTED] wrote:
On 3/10/08, Igor Vaynberg [EMAIL PROTECTED] wrote:
On Mon, Mar 10, 2008 at 7:39 PM, James Carman
[EMAIL PROTECTED] wrote:
If I'm developing a Hibernate-based application and I want to install
some global StateObjectStateException handling code, what's the best
way to do it? I could override Application.newRequestCycle()
providing my own request cycle implementation which overrides the
onRuntimeException() method. Is there a way to plug in logic which
says if you see exception type X, use this handler?
notice requestcycle.onruntimeexception() has access to the exception,
and returns a page, so
myrc.onruntimexception(runtimeexception e) {
if (e.getrootcause() instanceof hibernateexception) {
return new hibernateerrorpage(e);
}
}
Okay, so this is the way to handle it, eh? I just wanted to make sure
there was nothing out there already for this. I may make up a
Spring-based solution that allows me to register an exception
handler for specific types of runtime exceptions. That way, my forms
don't need to know I'm using Hibernate. They can just deal with my
domain interface (a repository). Thanks for the tip!
What if we changed IRequestCycleSettings to include these methods:
public void addRuntimeExceptionHandler(Class exceptionClass,
IRuntimeExceptionHandler handler);
public IRuntimeExceptionHandler getRuntimeExceptionHandler(RuntimeException e);
Then, add the IRuntimeExceptionHandler interface:
public interface IRuntimeExceptionHandler
{
public Page onRuntimeException(Page page, RuntimeException e);
}
Then, RequestCycle's onRuntimeException() method as follows:
public void onRuntimeException(Page page, RuntimeException e)
{
IRuntimeExceptionHandler handler =
Application.get().getRequestCycleSettings().getRuntimeExceptionHandler(e);
if( handler != null )
{
return handler.onRuntimeException(page,e);
}
return null;
}
This way, folks could install their own exception handlers very
easily. The getRuntimeExceptionHandler() method would do a search up
the class hierarchy if necessary, so you could install a handler for
IOException which would cover FIleNotFoundException, for instance.
What do you think?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Global Exception Handling...
you might also need access to the request cycle inside the
exceptionhandler, so thats three arguments now...maybe on exception
you want to set a 503 error
also what is the search order for handler resolution? do we go root
cause-outer or outer-root cause? both can make sense in certain
situations which would make handler resolution ambiguous...
we prefer to keep wicket bare and let users come up with their own
solutions for these sorts of thing, that work exactly how they want.
-igor
On Mon, Mar 10, 2008 at 9:20 PM, James Carman
[EMAIL PROTECTED] wrote:
On 3/10/08, James Carman [EMAIL PROTECTED] wrote:
On 3/10/08, Igor Vaynberg [EMAIL PROTECTED] wrote:
On Mon, Mar 10, 2008 at 7:39 PM, James Carman
[EMAIL PROTECTED] wrote:
If I'm developing a Hibernate-based application and I want to install
some global StateObjectStateException handling code, what's the best
way to do it? I could override Application.newRequestCycle()
providing my own request cycle implementation which overrides the
onRuntimeException() method. Is there a way to plug in logic which
says if you see exception type X, use this handler?
notice requestcycle.onruntimeexception() has access to the exception,
and returns a page, so
myrc.onruntimexception(runtimeexception e) {
if (e.getrootcause() instanceof hibernateexception) {
return new hibernateerrorpage(e);
}
}
Okay, so this is the way to handle it, eh? I just wanted to make sure
there was nothing out there already for this. I may make up a
Spring-based solution that allows me to register an exception
handler for specific types of runtime exceptions. That way, my forms
don't need to know I'm using Hibernate. They can just deal with my
domain interface (a repository). Thanks for the tip!
What if we changed IRequestCycleSettings to include these methods:
public void addRuntimeExceptionHandler(Class exceptionClass,
IRuntimeExceptionHandler handler);
public IRuntimeExceptionHandler getRuntimeExceptionHandler(RuntimeException
e);
Then, add the IRuntimeExceptionHandler interface:
public interface IRuntimeExceptionHandler
{
public Page onRuntimeException(Page page, RuntimeException e);
}
Then, RequestCycle's onRuntimeException() method as follows:
public void onRuntimeException(Page page, RuntimeException e)
{
IRuntimeExceptionHandler handler =
Application.get().getRequestCycleSettings().getRuntimeExceptionHandler(e);
if( handler != null )
{
return handler.onRuntimeException(page,e);
}
return null;
}
This way, folks could install their own exception handlers very
easily. The getRuntimeExceptionHandler() method would do a search up
the class hierarchy if necessary, so you could install a handler for
IOException which would cover FIleNotFoundException, for instance.
What do you think?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Global Exception Handling...
On 3/11/08, Igor Vaynberg [EMAIL PROTECTED] wrote: you might also need access to the request cycle inside the exceptionhandler, so thats three arguments now...maybe on exception you want to set a 503 error also what is the search order for handler resolution? do we go root cause-outer or outer-root cause? both can make sense in certain situations which would make handler resolution ambiguous... we prefer to keep wicket bare and let users come up with their own solutions for these sorts of thing, that work exactly how they want. The request cycle is easy enough to access anywhere, RequestCycle.get() right? I hadn't thought of the root cause stuff, admittedly. However, just going up the main hierarchy is probably sufficient for a majority of use cases. If a user needs more advanced search capability, I guess they could do it themselves. Maybe the search algorithm could be put in the RequestCycle class' onRuntimeException() method itself. Then, all you'd have to do is override Application.newRequestCycle() and RequestCycle.onRuntimeException() to plug in your own advanced handler search capability. I think this sort of feature is a common enough need that it could be built in, but that's just my opinion. I'm somewhat new to the Wicket community, so maybe I just didn't get the Wicket philosophy. That doesn't mean that I won't offer suggestions that I find useful anymore. :) Keeping the core framework bare is a good approach. Another thought I had is that inside the new methods on Application, maybe it could call a factory instead of doing the logic itself. Then, the factory could be configured by subclasses to override the default behavior rather than having to implement the method themselves. For instance, you could come up with a IRequestCycleFactory interface. So, if I were to write a little project that does what I want w.r.t. this exception handler stuff, all someone would have to do in their application is plug in my IRequestCycleFactory implementation to get that functionality. They wouldn't have to extend my Application superclass (what if they wanted to use another library which requires the extension of an Application superclass also?). The same sort of stuff could be done for Sessions, etc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Global Exception Handling...
On Mon, Mar 10, 2008 at 9:55 PM, James Carman
[EMAIL PROTECTED] wrote:
On 3/11/08, Igor Vaynberg [EMAIL PROTECTED] wrote:
you might also need access to the request cycle inside the
exceptionhandler, so thats three arguments now...maybe on exception
you want to set a 503 error
also what is the search order for handler resolution? do we go root
cause-outer or outer-root cause? both can make sense in certain
situations which would make handler resolution ambiguous...
we prefer to keep wicket bare and let users come up with their own
solutions for these sorts of thing, that work exactly how they want.
The request cycle is easy enough to access anywhere, RequestCycle.get()
right?
im not a big fan of using threadlocals everywhere personally...we
guarantee certain ones, but they make unit testing, etc, a pita. i
would prefer passing the instance in.
I hadn't thought of the root cause stuff, admittedly.
we, as core devs, try to think of all angles before adding something
like this into core :)
However, just
going up the main hierarchy is probably sufficient for a majority of
use cases.
thats one data point. we would have to open this up to the community
before we make a decision though.
If a user needs more advanced search capability, I guess
they could do it themselves. Maybe the search algorithm could be put
in the RequestCycle class' onRuntimeException() method itself. Then,
all you'd have to do is override Application.newRequestCycle() and
RequestCycle.onRuntimeException() to plug in your own advanced handler
search capability. I think this sort of feature is a common enough
need that it could be built in, but that's just my opinion.
ok. this is making more sense. so we would change Page
onRuntimeException(RT e) to ExceptionHandler onRuntimeException(RT e),
and the default resolution algorithm will be what most people agree on
as the best default. on the other hand, you can just override
requestcycle.onruntimeexception(rt e) {
map
handlers=beanfactoryutils.beansoftypeincludingancestors(applicationcontext,exceptionhandler.class);
for (excpetionhandler handler:handlers.values()) {
if (handler.matches(e)) { return e.getPage(e); break; }
}
return super.onruntimeexception(e);
}
that is about 5 lines of code and it doesnt force a specific algorithm
or exception handler onto the user...
I'm somewhat new to the Wicket community, so maybe I just didn't get
the Wicket philosophy. That doesn't mean that I won't offer
suggestions that I find useful anymore. :)
definately please do. we appreciate all the feedback. please dont take
me pushing back as a way to discourage you.
Keeping the core framework
bare is a good approach.
our api surface area is already pretty large, makes the framework
harder to learn. so we try to keep it as small as possible, that is
not to say we do not implement new ideas/features.
Another thought I had is that inside the new methods on Application,
maybe it could call a factory instead of doing the logic itself.
Then, the factory could be configured by subclasses to override the
default behavior rather than having to implement the method
themselves. For instance, you could come up with a
IRequestCycleFactory interface. So, if I were to write a little
project that does what I want w.r.t. this exception handler stuff, all
someone would have to do in their application is plug in my
IRequestCycleFactory implementation to get that functionality. They
wouldn't have to extend my Application superclass (what if they wanted
to use another library which requires the extension of an Application
superclass also?). The same sort of stuff could be done for Sessions,
etc.
i believe most, all that i have worked on, wicket application have
their own custom subclass of webrequestcycle, so a factory wouldnt
really benefit anyone if it's only purpose is to make installing a
generic subclass easier. what you can do is create your own subclass
of webrequestcycle that has handler registration, that way users can
subclass yours instead of webrequestcycle and get the handler
functionality. you can, for example, store registered handlers in
application metadata facility.
-igor
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
How Runtime Exception Handling?
Hello, I am trying to handle to the runtime exception in Wicket, by default in the deployment mode it throws internal error. I want to redirect it to my error.jsp on my WEB-INF folder. this is what i am doing in my web.xml file error-page exception-typejava.lang.Exception/exception-type !-- Displays a stack trace -- location/error.jsp/location /error-page Problem: I still the see the internal error page not the error.jsp page. Thanks Rama -- View this message in context: http://www.nabble.com/How-Runtime-Exception-Handling--tp14869906p14869906.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Exception Handling
Hi All, I am working on a project and I am using wicket 1.3 for the view layer, spring for service layer, and oracle database. As you know there are two types of exception I need to take care of. One is the business logic exception thrown from the service layer and the other one is the RuntimeException. What is the best practice of handling these two type of exception in wicket. Should I override the RequestCycle.onRuntimeException() to handle both of the cases?! Regards, Suad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
