Butash, Bob wrote:
> 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)."
>
If you wouldn't mind, please open a feature request here:
https://javaserverfaces.dev.java.net/issues.
> 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.
>
Well, at least one person said that. I know of several frameworks that
make use of PLs
and haven't brought this complaint up.
> -----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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: users-help_at_javaserverfaces.dev.java.net
>
>