Hi Glen, On Fri, 2007-06-22 at 12:52 -0400, Glen Daniels 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()?
I had always assumed that cleanup() was the counterpart to init(), and thus would be called when a handler was "deregistered" thereby providing the handler with the ability to release resources that it had acquired. I'm happy to have it removed until someone actually needs that type of functionality. > 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. +1 > 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. > I assume that you mean removing the getHandlerDesc() method (and not removing the HandlerDescription being passed into the Handler) -- +1 if we're already modifying the Handler interface to remove the cleanup() method. > Comments/thoughts? If we're only going to do (1) or (3), but not both, then perhaps we shouldn't do either unless it provides a great enough improvement to the code quality such that it's worth forcing users to modify their implementations. > > Thanks, > --Glen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
