Butash, Bob wrote:
> I understand what the spec states, however I question the practice and
> the intent of the spec in this area. When is it ever valid processing
> to catch and eat an exception that was thrown from someone else that you
> have no context around handling.
>
I believe is was to handle the case where beforePhase() threw an
exception and
it was desirable to still have afterPhase() invoked for the other
listeners that executed
properly.
> Example I have a phase listener that can control access to the execution
> of a backing bean, this worked fine in JSF 1.1 since the exception would
> occur and short circuit the logic to my exception handling. Now the
> exception is getting swallowed and someone that is not authorized access
> to logic is being allowed in the front door.
>
> Exceptions are thrown for a reason, never in framework type code should
> they be blindly swallowed without allowing the invoking logic to be able
> to specify how they should be treated or handled.
>
> Thanks for the quick response. I'm not trying to shoot the messenger,
> just trying to understand the thought process.
>
That said, there are several options:
- Since the RI is open source, you can create a custom lifecycle based
off that code
that would suit your needs.
- A feature could be added to the RI that will cause the exception to
be thrown
instead of logged (disabled by default).
You may also submit feedback on the spec here:
https://javaserverfaces-spec-public.dev.java.net.
>
>
> -----Original Message-----
> From: Ryan.Lubke_at_Sun.COM [mailto:Ryan.Lubke_at_Sun.COM]
> Sent: Tuesday, September 25, 2007 1:09 PM
> To: users_at_javaserverfaces.dev.java.net
> Subject: Re: JSF 1.2 Phase Listeners and Exceptions
>
> Hello,
>
> Section 11.3 of the spec states that any exceptions thrown by the call
> to beforePhase() or afterPhase() of a PL should log and swallow them.
>
>
>
> Butash, Bob wrote:
>
>> Hello,
>>
>> I'm trying to convert a JSF 1.1 application to leverage JSF 1.2. In
>> my application I have made it available that phase listeners can
>> thrown an exception. I than catch that exception in my lifecycle's
>> execute method where I handle it. It appears with JSF 1.2 a
>> questionable coding practice was introduced in that exceptions are now
>>
>
>
>> merely logged and then eaten. Here is the code that I'm referring to:
>>
>>
>> catch (Exception e) {
>> if (LOGGER.isLoggable(Level.WARNING)) {
>> LOGGER.warning("phase("
>> + phaseId.toString()
>> + ','
>> + context
>> +
>> ") threw exception: "
>> + e
>> + ' '
>> + e.getMessage()
>> +
>> "\n"
>> + Util.getStackTraceString(e));
>> }
>> // move the iterator pointer back one
>> if (listenersIterator.hasPrevious()) {
>> listenersIterator.previous();
>> }
>> }
>>
>> I know that the spec states that the after phase should be invoked,
>> however is eating exceptions the right move here???
>>
>> Thanks for your thoughts
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: users-help_at_javaserverfaces.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: users-help_at_javaserverfaces.dev.java.net
>
>