[jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-3520) Handling Exception (not only) when using JPDL Pageflows

[ahus1 (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBSEAM-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ahus1 updated JBSEAM-3520:
--------------------------

    Attachment: ExceptionAction.java
                ExceptionHandler.java


Added our implementations

> Handling Exception (not only) when using JPDL Pageflows
> -------------------------------------------------------
>
>                 Key: JBSEAM-3520
>                 URL: https://jira.jboss.org/jira/browse/JBSEAM-3520
>             Project: Seam
>          Issue Type: Feature Request
>          Components: BPM
>    Affects Versions: 2.0.2.SP1
>         Environment: seam with jpdl
>            Reporter: ahus1
>         Attachments: ExceptionAction.java, ExceptionHandler.java
>
>
> The problem: when there are exceptions in a jpdl pageflow , you will not be able to continue with the pageflow if you are stuck at a transition node or a decision node. There is no chance to display the error message and to return to the last page. 
> The solution idea: Use an exception handler in the jpdl pageflow, store some information, reposition the pageflow on a page node in a seam exception handler. 
> The other problem: When this can be done for pageflows, can this be done for conversations as well?
> The other solution idea: This should work when there is an exception in the invoke application phase (in the POST-Phase), but when there is a GET request (rendering the view in the GET after POST) redirecting to the indentical view could lead to a infinite loop.
> This is how I do it manually, maybe there is a chance to these things automatically in seam: 
> (1) place an exception handler in every pageflow
>   <exception-handler exception-class="javax.el.ELException">
>     <action class="de.plusfinanzservice.common.bean.ExceptionAction" />
>   </exception-handler>
> In a jpdl pageflow with seam we usually use EL expressions, therefore all exceptions we get here are wrapped in an EL Exception. First we unwrap them.
> We determine the source of the transition. If the source is a decision node (and not a page node), we will need to find the error handling page node. Our convention is to use a "failure" transition on every decision node to do exactly that. The data is saved on a new seam bean exception handler.
> (2) pick up all exceptions in pages.xml
> <exception class="java.lang.Exception">
>     <redirect view-id="#{exceptionHandler.getViewId('/iss/error.jspx')}">
>       <message severity="error">
>         #{messages[exceptionHandler.getMessage(org.jboss.seam.handledException)]}
>       </message>
>     </redirect>
>   </exception>
> After collection the right information in the exception action, reposition in the exception handler is easy:
>       if (node != null) {
>         Pageflow.instance().reposition(node);
>         retVal = Pageflow.instance().getPage().getViewId();
>       } 
> This exception handler tries to do "the right thing" even if you are not in a pageflow. For GET requests it assumes that the exception has been raised in the render view phase and no recovery is possible. If not, I tries to forward you to the last known view (using conversation information). The message to be displayed is extracted from the Exception. 
> Final thoughts: maybe it would be a good idea to create a two phase solution. One basic with exception handling. And another one that extends it that adds jpdl handling. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira