struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pedro Rodriguez" <prodr...@accovia.com>
Subject [Struts Workflow] - Processing "newState" and "endWorkflow" before executing the Action
Date Mon, 17 Nov 2003 15:50:58 GMT
I think it is not a good idea to process "newState" and "endWorkflow"
before executing the Action. 
 
Problem:
 
The fact is that an Action can fail. If that happens, such anticipated
state transitions and cleanups are undesired.
 
Drawbacks of the current design:
 
If an Action mapping includes "newState" or "endWorkflow" then some sort
of "rollback" must be defined to handle Action's failures.
 
Instead of going directly to a jsp on every failure (as normal) we
should navigate to a "rollback" action mapping where all modified
workflows states are restituted. The challenge here is to know which
such state was!!!
 
Also, the custom rollback implementation must provide the reactivation
of those workflows prematurely destroyed.
 
Solution
 
Struts don't formalize "Action failure" so there is no way for
StrusWorkflow to know if the Action succeeded or not. 
 
However, we should define one. For example, a property "failureForward".

 
The user can specify all forwards representing failures (adding
failureForward properties to the Action mapping). 
 
In Struts, using the resulting forward path we can determine the
forward. 
 
If no forward can be determined (no forward was used to create the
resulting forward path) or if the resulting forward doesn't represent a
failure then we proceed to perform the specified "newState" and
"endWorkflow.
 
If the action fails, no "newState" nor "endWorkflow" must be processed.
 
The WorkflowRequestProcessor/TilesWorkflowRequestProcessor can easily
handle that. 
 
Unhandled exceptions
 
The same discussed for Action failures forwards applies for uncatched
exceptions.
 
If the Action execution is aborted due to an uncatched exception (being
handle by a Struts error handler or whatever) no "newState" nor
"endWorkflow" shouldn't be processed either.
 
Pedro Rodriguez
 
 

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message