Glen, +1 to #1 and #2. I think we should leave #3 as-is. If we do just #1 and #2, people who already have classes that implement Handler's will not have to change anything.
thanks, dims On 6/22/07, Glen Daniels <[EMAIL PROTECTED]> wrote:
A few questions about the Handler interface based on recent conversations: 1) cleanup() never gets called. Can we remove it now that we've got flowComplete()? 2) flowComplete() seems somewhat flawed in that there is currently no way (AFAICT) to conclusively determine whether it is being called as a result of a fault/thrown exception or due to the normal termination of processing. This leaves no easy way for Handler developers to do rollbacks of any work they've done. It appears we used to have revoke(), which I think seems like the right thing (it's easier to code an explicit fault handler API than it is to remember to check for something that the compiler won't tell you about), but that was apparently replaced with flowComplete()? PROPOSAL - add a "failureReason" field (of type Exception) to MessageContext, and ensure that the engine ALWAYS sets this if we have to back out the processing chain due to an error. Leave flowComplete() as is, but now implementors can mc.getFailureReason() and react appropriately. 3) Why are we forcing every Handler to keep a pointer to it's HandlerDesc? We only call this in a couple of places (Phase), and IMHO it clutters up the interface unnecessarily. It seems like Phase should be keeping HandlerDescs, and those should be pointing to Handlers... that would more loosely and cleanly decouple the two classes. Comments/thoughts? Thanks, --Glen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Davanum Srinivas :: http://davanum.wordpress.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
