I don't understand why you would like to handle
Converter/ValidatorExceptions? Those are handled by the JSF framework and
automatically put into the FacesContext as FacesMessages. You can then just
show them on your page using UIMessage(s). She only place where
Business/SystemExceptions are thrown, is in an ActionListener, since that is
your gateway to the other layers.

If you really need to handle Converter/ValidatorExceptions, just put a
PhaseListener before RENDER_RESPONSE and inspect the messages in your
FacesContext. If it contains any ERROR or FATAL messages (you can use
getMaximumSeverity), do something, otherwise do something else.

I understand the MyFaces specific approach has advantages, like ease of use,
but it's usually good to use standard mechanisms (if you can, in a
reasonable way). It's also possible to just use a Servlet Filter or a custom
FacesServlet that extends the standard FacesServlet to handle exceptions,
but I wouldn't reccomend those two options.

Regards,

Jan-Kees


2008/9/25 Zied Hamdi <[EMAIL PROTECTED]>

> Hi Leonardo and Jan,
>
> Sorry for the delay, I didn't have time to look at my mail these latter
> days.
>
> Thanks Leonardo a lot for your resource: it is exactly what I was searching
> for. This is not a standard JSF solution (so my expectations were right ;-)
> the part I was interested in is:
>
> <!-- if you want to choose a different class for handling the exception - the 
> error-handler needs to include a method handleException(FacesContext fc, 
> Exception ex)-->
>   <context-param>
>
>     <param-name>org.apache.myfaces.ERROR_HANDLER</param-name>
>     <param-value>my.project.ErrorHandler</param-value>
>   </context-param>
>
>
> Thanks to you Jan also for your answer, your solution is perfect for action
> handling, unfortunately it doesn't cover Conversion and Validation phases.
>
> Best Regards,
> Zied
>
> Your answer
> 2008/9/23 Jan-Kees van Andel <[EMAIL PROTECTED]>
>
> If you want application specific error handling, you can always create a
>> custom ActionListener. That ActionListener is actually a decorator that
>> "decorates" the real ActionListener with a try-catch block. All your calls
>> to actions, go through that listener. In the catch, you can build any error
>> handling mechanism you want.
>>
>> Just declare your class inside faces-config.xml, like this:
>> <application>
>>   <action-listener>
>>     some.package.CustomActionListener
>>   </action-listener>
>> </application>
>>
>> Your ActionListener must implement javax.faces.event.ActionListener.
>> Implementing the class won't be difficult.
>>
>> One caveat, you may not place Exception throwing inside getters or setters
>> anymore, only actions, since the custom listener only wraps those calls.
>>
>> Regards,
>>
>> Jan-Kees
>>
>>
>> 2008/9/23 Leonardo Uribe <[EMAIL PROTECTED]>
>>
>>
>>>
>>> On Tue, Sep 23, 2008 at 5:40 AM, Zied Hamdi <[EMAIL PROTECTED]> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Does the no answer to my mail mean "there's no answer"? :-)
>>>>
>>>
>>> Do you seen http://wiki.apache.org/myfaces/Handling_Server_Errors   ?
>>>
>>> regards
>>>
>>> Leonardo Uribe
>>>
>>>
>>>>
>>>> Regards,
>>>> Zied
>>>>
>>>> 2008/9/22 Zied Hamdi <[EMAIL PROTECTED]>
>>>>
>>>> Hi all,
>>>>>
>>>>> I used to have in all my apps a "J2ee like" mecanism that defines two
>>>>> basic exceptions Business and System, where business messages include a 
>>>>> i18n
>>>>> message and system one lead to an unconditional output. In a central place
>>>>> (eg. for struts it was the superclass of all actions), I organized my 
>>>>> output
>>>>> against the exception type and message key. That way in my app I never had
>>>>> to to handle error presentation in my business logic (instead i was 
>>>>> throwing
>>>>> general or sometimes specialized exceptions and handling that later (even 
>>>>> in
>>>>> the application developement cycle)).
>>>>>
>>>>> Attemping to do the same with JSF I have a big problem there's no way
>>>>> to do it through standard JSF extentions, even more, the class I have to
>>>>> override depends on the specific implementation (it is not in the
>>>>> jsf-api.jar) eg. for the mojarra impl I have to overrride
>>>>> com.sun.faces.lifecycle.LifecycleImpl's execute method:
>>>>>
>>>>>     public void execute(FacesContext context) throws FacesException {
>>>>>
>>>>>         if (context == null) {
>>>>>             throw new NullPointerException
>>>>>                 (MessageUtils.getExceptionMessageString
>>>>>                  (MessageUtils.NULL_PARAMETERS_ERROR_MESSAGE_ID,
>>>>> "context"));
>>>>>         }
>>>>>
>>>>>         if (LOGGER.isLoggable(Level.FINE)) {
>>>>>             LOGGER.fine("execute(" + context + ")");
>>>>>         }
>>>>>
>>>>>         for (int i = 1, len = phases.length -1 ; i < len; i++) { //
>>>>> Skip ANY_PHASE placeholder
>>>>>
>>>>>             if (context.getRenderResponse() ||
>>>>>                 context.getResponseComplete()) {
>>>>>                 break;
>>>>>             }
>>>>>
>>>>>             phases[i].doPhase(context, this, listeners.listIterator());
>>>>>
>>>>>         }
>>>>>
>>>>>     }
>>>>>
>>>>> by surrounding it with a try-catch block that delegates exception
>>>>> handling to the class responsible for that (to add FacesMessage(s)).
>>>>>
>>>>> Then I have to rely on the classloader to find my class before the one
>>>>> in the jar with the same name. I think this is also transgrating the sun
>>>>> licence that allows me to use the classes as is.
>>>>>
>>>>> The procedure is similar with the myFaces implementation with the
>>>>> exception that the Apache licence lets me do this manipulation legally. 
>>>>> (But
>>>>> I'm using JBoss wich bundles the RI so there's also work to do to switch
>>>>> implementations)
>>>>>
>>>>> All this is to ask if anoyone knows about a less acrobatic way to have
>>>>> the needed behavior. Notice that I want to use the same exceptions for
>>>>> validators and converters also that's why I intercept the overall phasis
>>>>> cycle rather than the com.sun.faces.lifecycle.InvokeApplicationPhase 
>>>>> class.
>>>>>
>>>>> Also note that javax.faces.validator.DoubleRangeValidator (as an
>>>>> example) uses this same schema in conjunction with the
>>>>> javax.faces.component.UIInput that expects this type of exceptions and
>>>>> handles it specifically. I want to expand this schema to the whole
>>>>> application.
>>>>>
>>>>>
>>>>> Your help is very appreciated, I really don't want to get out of the
>>>>> standard procedure.
>>>>>
>>>>> Kind Regards,
>>>>> Zied
>>>>>
>>>>> --
>>>>> Zied Hamdi
>>>>> www.into-i.fr
>>>>> (previously in 2003)
>>>>> zatreex.sf.net
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Zied Hamdi
>>>> www.into-i.fr
>>>> (previously in 2003)
>>>> zatreex.sf.net
>>>>
>>>
>>>
>>
>
>
> --
> Zied Hamdi
> www.into-i.fr
> (previously in 2003)
> zatreex.sf.net
>

Reply via email to