[
https://issues.apache.org/jira/browse/DELTASPIKE-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko reassigned DELTASPIKE-559:
--------------------------------------------
Assignee: Thomas Andraschko
> ExceptionHandler lifecycle
> --------------------------
>
> Key: DELTASPIKE-559
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-559
> Project: DeltaSpike
> Issue Type: Bug
> Components: JSF-Module
> Affects Versions: 0.6
> Reporter: Moritz Bechler
> Assignee: Thomas Andraschko
> Priority: Critical
> Fix For: 0.7
>
>
> From the original ticket:
> [quote]
> Generally, I'm also a bit confused by the exception handler setup, it looks
> like there is a application global instance held by the exception handler
> factory. Besides I don't think this is thread safe and the spec says
> ExceptionHandlers are request scoped - if there is an error while processing
> the exception or there is no other ExceptionHandler defined (e.g. Myfaces
> without org.apache.myfaces.ERROR_HANDLING=true) exceptions will not be
> removed and indefinitely delivered (ExceptionHandlerBroadcaster throws
> without marking as handled if there are no deltaspike handlers) for unrelated
> requests.
> [quote]
> Thought a bit more about this. By holding onto the wrapped exception handler
> in the exception handler factory, deltaspike effectively breaks the contract
> (application scoped vs. expected request scoped lifecycle) for all wrapped
> exception handlers. I can think of a very broad range of errors that may
> result from this - depending on the wrapped exception handlers (including the
> exceptions are delivered on every subsequent request error if unhandled).
> Imho, deltaspike must create a new exception handler in
> DeltaSpikeExceptionHandlerFactory.getExceptionHandler(). If retaining the
> exception events over requests is desired some out of band mechanism must be
> used.
> Moritz
--
This message was sent by Atlassian JIRA
(v6.2#6252)
