I'm not to happy to have a method like that in the Application object
in the first place. First of all, as you can replace the request
processing strategy, it is in fact not really needed, but mere
convenience. And as a convenience method, I think it would make much
more sense to have that (still overridable) method part of the request
cycle. Imo, the scoping would be more logical. But really, I'm still
thinking about whether we should provide such a convenience method in
the first place.

Eelco


On 12/18/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> hi guys, looks like our latest request cycle refactoring broke
> onRuntimeException handler in Application. i looked into fixing it and there
> doesnt seem to be a very clean way.
>
>  first, we no longer deal with a runtime exception, our
> IExceptionResponseStrategy now deals with a regular exception. so i renamed
> onRuntimeException to onException and it now takes a regular exception as a
> param.
>
>  secondly it is now public since the response strategy and application are
> no longer in the same package.
>
>  finally there is also some weirdness in mock application since you cant
> rethrow a checked exception without declaring it so i have to wrap it in a
> runtime exception which is not what user might expect.
>
>  im attaching the patch. if no one is against this fix i will commit it.
> just wanted to check since this will break some clients.
>
>  -Igor
>
>
>


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop

Reply via email to