]
Johan Gärde updated JBSEAM-4395:
--------------------------------
Attachment: Fix_for_JBSEAM-4395.patch
Modified the pages.xml parser for exceptions so that it reads the before-redirect
attribute of the end-conversation element. The RedirectHandler makes use of this
information and ends the conversation before or after the redirect as specified.
Endless loop when an exception occurs during commit inside a long
running conversation, and there is an <exception> clause to handle it in page.xml
---------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBSEAM-4395
URL:
https://issues.jboss.org/browse/JBSEAM-4395
Project: Seam 2
Issue Type: Bug
Components: Exception Handling
Affects Versions: 2.2.0.GA, 2.2.1.CR1
Environment: WebSphere v7.0.0.5, Seam 2.2.1-SNAPSHOT
Reporter: Denis Forveille
Attachments: Fix_for_JBSEAM-4395.patch
Scenario:
- process is in a long running conversation
- a persistence exception occurs (e.g. OptimisticLockingException), during either a call
to flush() or during the automatic commit() of the transaction
- a clause <exception> is declared in pages.xml to handle the exception and
redirect to a generic error page (e.g. <exception> that will handle all
exceptions..) like this:
<exception>
<end-conversation/>
<redirect view-id="/erreur_exception.xhtml" />
</exception>
During the commit, the exception occurs, Seam catch it and pass it to the exception
handler.
The exception handler sees that the user has to be redirected to the error page.
The long running conversation is still active, handling the "dirty" objects
that cause the persistence failure
The request to process the error page starts. During the "RESTORE_VIEW", the
dirty object that are in the conversation are then flushed again to the database, causing
again the persistence exception, triggering the seam exception handling mechanism, that
will redirect to the error handling page, causing an endless loop
A workaround to this is to add an observer on "org.jboss.seam.exceptionHandled"
that will kill the current conversation and so remove the dirty objects from the session
and the error page is display (see the forum reference)
Some thoughts:
- the documentation gives an example on how to handle OptimisticLockingException, but in
our case, the way it is, this causes an infinite loop
- is the <end-conversation/> clause working correctly? At what time during
exception handling is the end-conversation supposed to occur?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: