1 Reply Latest reply: Jan 10, 2013 10:53 AM by Johan Gärde RSS

problems with redirect in exception handling in pages.xml

Immo Benjes Newbie



I've got a problem with the redirect when handling an exception in pages.xml



<exception class="MyApplicationException">
  <end-conversation before-redirect="true"/>  
  <redirect view-id="/secure/EntityView.xhtml">
                              <message severity="INFO">#{messages['cancel.rollback']}</message>
  <param name="name" value="value"/>







The user is on an 'edit' page of an entity (and related entities). When the user presses the cancel button all changes should be reverted. I throw an exception that is annotated with



So far so good. The exception is thrown and the transaction is rolled back. Now I want to redirect to a page where the original entity is shown. The backing bean is the same for the edit page.


I've added the code above to pages.xml, I wanted to pass in a page parameter to the page which tells me what entity to display however the <param/> is ignorred and I only get


/secure/EntityView.seam?cid=2  (where the cid did not change from the EntityEdit.seam page. Shouldn't this be a different cid as I've got end-conversation before redirect?)


How can I pass over the information on that entity if it is from one instance of a seam component A to the next instance of the same component A?


Another problem I have is when I try to redirect to a another page. Here I get a LIE exception telling me that no session is available. So it seems somehow the old conversation is not ended (or no new one is being created and the rolled back transaction is still used).


Thanks for your help

  • 1. Re: problems with redirect in exception handling in pages.xml
    Johan Gärde Newbie

    Seam 2.2.2 does not even read the before-redirect attribute of the end-conversation element when parsing exception elements in pages xml, i.e. your conversation will not be ended before the redirect when your exception is handled by Seam even if your pages.xml states it should. See jira issue JBSEAM-4395 for a discussion on the subject, a workaround and a proposed fix.