Hi Sanjiva!
Sanjiva Weerawarana wrote:
Thoughts?
Looks good to me, but I'm a bit skeptical about onComplete vs.
onMessage. While in theory I can see the need is this practically
useful? If someone wants to check whether the MEP is complete when a
message has been delivered, they can go up to the operation context and
check the state. So, do we really need onComplete?
I was just thinking about cases where the MEP completes as a result of
something other than a message receipt. For instance - when an outgoing
message send has completed, or when an error occurs. It might be nice
to have a single place where cleanup, etc, can happen without needing to
know exactly how the MEP was closed. It also lets the system do that
work (determining the end of an MEP) for you instead of having to
replicate it in your callback classes. I'm not tied to it though.
An important point to put into the javadocs is that onError is not
called for fault messages- its only called when something has gone
wrong. Receiving a message that contains a fault is not an error; just
business as usual.
+1, although I would also support letting the system do the isFault()
check for you and having separate onMessage() and onFault() APIs in the
callback class if people thought that would be less prone to coder error.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
