Workflows can't be destroyed and aren't properly injected

[GoogleCodeExporter]

This is going to be a major API change, but no one should notice it since
nothing is using workflows except JCatapult internals. 

The reason that workflows need to be changed is that some workflows are
request based processors that get injected with the HttpServletRequest or
they use other classes that are injected with the HttpServletRequest.
However, when the container is shutting down it calls the destroy method on
all the workflows. This method requires that an instance of the Workflow be
created. If that Workflow or any class it uses needs the
HttpServletRequest, it won't be available at this time and Guice throws
exceptions.

However, some Workflow's need to be destroyed, so we'll need a separate
interface for that. These Workflow's will have to understand the
consequences of being Destroyable and will not be allowed to inject the
HttpServletRequest or HttpServletResponse at all, including the classes
they use.

Furthermore, many Workflow objects don't need the HttpServletRequest and
HttpServletResponse to be passed to them and those that do can easily be
modified to have it injected. This correctly changes the semantics so that
the Workflow instances are truly request based processors. In order to
accomplish this, the Workflow's perform method needs to be modified and so
does the WorkflowChain's method. As long as I'm breaking everything, I'm
also going to change the WorkflowChain's method to be named *continueWorkflow*.

Original issue reported on code.google.com by bpontare...@gmail.com on 18 Jun 2008 at 2:01

[GoogleCodeExporter]

Fixed this for RC5. The workflows are now all injected with the request and 
there is
a new interface called DestroyableWorkflow.

Original comment by bpontare...@gmail.com on 9 Jul 2008 at 10:52

• Changed state: Fixed