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