Jumping in a little late here, but I had to wrestle with this for JAX-WS so
I have a little experience.
In the current implementation, we (OperationClient) return an AxisFault to
onError with the actual fault message that was returned. To Dims' question
of how we get the MessageContext in that instance, there is a MC stuffed on
the AxisFault (I know, not pretty at all) that contains the actual fault
message. I surfaced this on the list some time ago and no one had any
issues with using that mechanism to get the fault for JAX-WS clients.
Like I said though, I wasn't completely comfortable with this so I'm glad
to see that this is being cleaned up as I wasn't always so comfortable with
that API.
I would prefer that there be a separate onFault() rather than having
everything coming back through onMessage(). I agree with Glen's last
comment that it makes it a little cleaner from a coder's perspective to
have the system identify for you when it's a fault rather than having them
do it themselves.
Regards,
-Nick
Glen Daniels
<[EMAIL PROTECTED]
t.com> To
axis-dev@ws.apache.org
05/08/2007 08:13 cc
AM
Subject
Re: [Axis2]
Please respond to org.apache.axis2.client.async.Callb
[EMAIL PROTECTED] ack#onError method signature
e.org
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]
<<inline: graycol.gif>>
<<inline: pic05769.gif>>
<<inline: ecblank.gif>>
