You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by "Gerhard Petracek (JIRA)" <ji...@apache.org> on 2014/09/17 00:34:34 UTC

[jira] [Resolved] (DELTASPIKE-723) Exception bypassing on JSF conversion errors

     [ https://issues.apache.org/jira/browse/DELTASPIKE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gerhard Petracek resolved DELTASPIKE-723.
-----------------------------------------
    Resolution: Fixed

> Exception bypassing on JSF conversion errors
> --------------------------------------------
>
>                 Key: DELTASPIKE-723
>                 URL: https://issues.apache.org/jira/browse/DELTASPIKE-723
>             Project: DeltaSpike
>          Issue Type: Bug
>    Affects Versions: 1.0.1
>            Reporter: Sven Linstaedt
>             Fix For: 1.0.3
>
>
> {{org.apache.deltaspike.jsf.impl.injection.proxy.DelegatingMethodHandler}} is not catching {{java.lang.reflect.InvocationTargetException}} from method invocations causing any kind of exceptions from converters and validators being thrown wrapped in InvocationTargetException.
> Especially when in comes to conversion this will cause {{javax.faces.component.UIInput.validate(FacesContext)}} fail to catch {{javax.faces.convert.ConverterException}} from any converters.
> To make things worse (and me scratching my head for several hours while trying to find out, how this "ConverterException" can bypass the before mentioned catch block from UIInput) BridgeExceptionHandlerWrapper returned by DeltaSpikeFacesContextWrapper is unfortunately only returning the unwrapped ConverterException to the application, so any trace of this catch block bypassing is cleaned up and therefore perfectly hidden from the application.
> To sum up: Current deltaspike releases > 1.0.0 are causing JSF based applications to fail on conversion errors, making these releases unusable.
> Possible solution: Catching the InvocationTargetException in DelegatingMethodHandler and rethrowing it's target exception will probably do the job, but as I peeked into the code MethodHandlerProxy and DelegatingMethodHandler seem to be a temporary solution, so maybe there is already another solution for this problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)