I think the latter approach would be best:
"A feature could be added to the RI that will cause the exception to be
thrown
instead of logged (disabled by default)."
We already have a custom lifecycle that merely wraps the reference
implementation's LifecycleImpl. This allows us some exception handling
capabilities. However we do not want to customize or alter the
underlying processing logic as to impact the ability to easily pull in
newer versions of the code.
There is also a thread that was discussing this issue at:
http://forum.java.sun.com/thread.jspa?threadID=662657
The basic response has been that people stopped using phase listeners
once this change went in.
-----Original Message-----
From: Ryan.Lubke_at_Sun.COM [mailto:Ryan.Lubke_at_Sun.COM]
Sent: Tuesday, September 25, 2007 1:39 PM
To: users_at_javaserverfaces.dev.java.net
Subject: Re: JSF 1.2 Phase Listeners and Exceptions
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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_javaserverfaces.dev.java.net
For additional commands, e-mail: users-help_at_javaserverfaces.dev.java.net