[
http://jira.jboss.com/jira/browse/JBSEAM-1277?page=comments#action_12366614 ]
Chris Rudd commented on JBSEAM-1277:
------------------------------------
I have resolved this by making the following modifications :
ExceptionFilter.java
protected void endWebRequestAfterException(HttpServletRequest request,
HttpServletResponse response, Exception e)
throws ServletException, IOException
{
log.debug("ending request");
//the FacesContext is gone - create a fake one for Redirect and HttpError to call
MockFacesContext facesContext = createFacesContext(request, response);
facesContext.setCurrent();
+ // Flush session and conversation contexts as the request did not end correctly due
to the exception.
+ if (Contexts.isConversationContextActive())
+ {
+ if (!Init.instance().isClientSideConversations())
+ {
+ Contexts.getConversationContext().flush();
+ }
+ }
+ if (Contexts.isSessionContextActive())
+ {
+ Contexts.getSessionContext().flush();
+ }
+
ServerConversationContext does not process removals / additions when
an exception propagates up
-----------------------------------------------------------------------------------------------
Key: JBSEAM-1277
URL:
http://jira.jboss.com/jira/browse/JBSEAM-1277
Project: JBoss Seam
Issue Type: Bug
Components: Core
Affects Versions: 1.3.0.ALPHA, 1.2.1.GA, 1.2.0.GA
Reporter: Chris Rudd
I have an Stateful EJB Component that throws an exception (this is expected, im testing
that the system can recover from that error). This causes the component to be removed from
the seam contexts (via the RemoveInterceptor). Then the exception floats up and is caught
by the ExceptionFilter, and is redirected to a new view. All that works correctly. BUT
when I return to the conversation that contained the EJB component, the component is still
in it (even though the RemoveInterceptor removed it).
Ive traced it down to this :
ServerConversationContext.remove -- this adds the removal to the removals list, but does
not update the session.attributes (the real storage for the context).
ServerConversationContext.flush -- this applies the removals / additions to the session
attributes map.
The problem is that flush is never called when an exception propagates out. Thus the
changes to that context are never flushed to the session attributes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira