You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Davanum Srinivas <da...@gmail.com> on 2007/05/07 15:34:00 UTC
[Axis2] org.apache.axis2.client.async.Callback#onError method signature
Folks,
Here's the current signatures for onError for async callback's. How do
i get access to the MessageContext and or the envelope when i onError
gets called?
public abstract class Callback {
public abstract void onComplete(AsyncResult result);
public abstract void onError(Exception e);
}
Does it make sense to change the method as follows? Basically add an
extra paramter in onError?
public abstract class Callback {
public abstract void onComplete(AsyncResult result);
public abstract void onError(Exception e, AsyncResult result);
}
Thanks,
dims
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] org.apache.axis2.client.async.Callback#onError method signature
Posted by Nicholas L Gallardo <nl...@us.ibm.com>.
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
<glen@thoughtcraf
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
axis-dev@ws.apach 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] org.apache.axis2.client.async.Callback#onError method
signature
Posted by Glen Daniels <gl...@thoughtcraft.com>.
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] org.apache.axis2.client.async.Callback#onError method signature
Posted by Davanum Srinivas <da...@gmail.com>.
+1 Glen. Let's do it.
-- dims
On 5/8/07, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi Dennis!
>
> Dennis Sosnoski wrote:
> > Rather than changing the existing methods, I suggest just adding a
> > MessageContext field and get/set methods. That way the engine can call
> > setMessageContext(ctx) before calling setComplete(), and any clients
> > that want to access the context can use the getMessageContext() method
> > for access. It's not pretty, but it at least avoids breaking
> > compatibility with existing client code.
>
> Ugh. :(
>
> Here's my take on this. Axis2 is still pretty brandy-new, and right now
> there are many fewer people using it than we hope to have in a year, or
> two years, or five. There are some places in our stack of APIs that
> are... "suboptimal" comes to mind but that's really a euphemism. :) We
> can either say "well that's life" and continue trying to build a vast
> global user base for a stack we know will continue to be flawed forever
> (until we get fed up enough to do Axis3!), or we can try to fix these
> kinds of cleanliness/design issues ASAP with as much care as we can -
> and look forward to an even bigger vast global user base because our
> APIs will be easy, clean, and make sense.
>
> I'd much rather fix what problems we can now. Yes, it will affect our
> current user base, but we can be as friendly about it as possible using
> deprecation, and the Axis2 1.2 users are still pretty much early
> adopters so I don't think it'll be too egregious for them.
>
> So the net is - your solution would work, but I would MUCH rather do the
> following. Deprecate the current Callback class, but still support it
> in old code for at least one full release cycle (I haven't looked deeply
> into this but I assume it's doable). Add a new class AxisCallback with
> the API that we end up with on this thread, and use that into the future.
>
> Thoughts?
>
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] org.apache.axis2.client.async.Callback#onError method
signature
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Dennis!
Dennis Sosnoski wrote:
> Rather than changing the existing methods, I suggest just adding a
> MessageContext field and get/set methods. That way the engine can call
> setMessageContext(ctx) before calling setComplete(), and any clients
> that want to access the context can use the getMessageContext() method
> for access. It's not pretty, but it at least avoids breaking
> compatibility with existing client code.
Ugh. :(
Here's my take on this. Axis2 is still pretty brandy-new, and right now
there are many fewer people using it than we hope to have in a year, or
two years, or five. There are some places in our stack of APIs that
are... "suboptimal" comes to mind but that's really a euphemism. :) We
can either say "well that's life" and continue trying to build a vast
global user base for a stack we know will continue to be flawed forever
(until we get fed up enough to do Axis3!), or we can try to fix these
kinds of cleanliness/design issues ASAP with as much care as we can -
and look forward to an even bigger vast global user base because our
APIs will be easy, clean, and make sense.
I'd much rather fix what problems we can now. Yes, it will affect our
current user base, but we can be as friendly about it as possible using
deprecation, and the Axis2 1.2 users are still pretty much early
adopters so I don't think it'll be too egregious for them.
So the net is - your solution would work, but I would MUCH rather do the
following. Deprecate the current Callback class, but still support it
in old code for at least one full release cycle (I haven't looked deeply
into this but I assume it's doable). Add a new class AxisCallback with
the API that we end up with on this thread, and use that into the future.
Thoughts?
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] org.apache.axis2.client.async.Callback#onError method
signature
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Callback is part of the public API for Axis2, so I think incompatible
changes should be avoided if at all possible.
Rather than changing the existing methods, I suggest just adding a
MessageContext field and get/set methods. That way the engine can call
setMessageContext(ctx) before calling setComplete(), and any clients
that want to access the context can use the getMessageContext() method
for access. It's not pretty, but it at least avoids breaking
compatibility with existing client code.
- Dennis
Dennis M. Sosnoski
SOA and Web Services in Java
Training and Consulting
http://www.sosnoski.com - http://www.sosnoski.co.nz
Seattle, WA +1-425-939-0576 - Wellington, NZ +64-4-298-6117
Sanjiva Weerawarana wrote:
> Glen Daniels wrote:
>>
>> First of all, is "onComplete()" really the right name for the
>> callback? If you have an MEP with multiple response messages,
>> mightn't this get called a few times? Perhaps onMessage() is better,
>> and then we can have onComplete() be a separate callback to indicate
>> that the MEP is done.
>>
>> Second, what's the point of AsyncResult? It contains nothing except
>> a MessageContext right now. Recommend dropping this class.
>>
>> Third, why is Callback an abstract class and not just an interface?
>> There doesn't seem to be enough going on there (really just setting
>> the "complete" flag) to warrant the limitations that you get when
>> extending instead of implementing.
>>
>> Fourth, if you get an onError(), does that mean you a) received a
>> fault message, or b) something went wrong on our side? In other
>> words, which MessageContext would we even be receiving here? I think
>> it would be clearer and cleaner to have all received messages,
>> including faults, be handled by onMessage(), and then have onError()
>> be explicitly for the case where something went wrong while sending.
>> Alternately I'd be ok with separate onFault() and onError().
>>
>> So I'd propose the following:
>>
>> public interface Callback {
>> /**
>> * Received a message, info in the MessageContext. Might be a
>> * fault, so check msgContext.isFault()!
>> */
>> void onMessage(MessageContext msgContext);
>>
>> /**
>> * Operation is complete. (should we pass OperationContext?)
>> */
>> void onComplete();
>>
>> /**
>> * Something went wrong on our side! The MessageContext
>> * is the OUTGOING message. Incoming faults will trigger the
>> * onMessage() callback above.
>> */
>> void onError(Exception e, MessageContext msgContext);
>> }
>>
>> 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?
>
> 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.
>
> Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] org.apache.axis2.client.async.Callback#onError method
signature
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Glen Daniels wrote:
>
> First of all, is "onComplete()" really the right name for the callback?
> If you have an MEP with multiple response messages, mightn't this get
> called a few times? Perhaps onMessage() is better, and then we can have
> onComplete() be a separate callback to indicate that the MEP is done.
>
> Second, what's the point of AsyncResult? It contains nothing except a
> MessageContext right now. Recommend dropping this class.
>
> Third, why is Callback an abstract class and not just an interface?
> There doesn't seem to be enough going on there (really just setting the
> "complete" flag) to warrant the limitations that you get when extending
> instead of implementing.
>
> Fourth, if you get an onError(), does that mean you a) received a fault
> message, or b) something went wrong on our side? In other words, which
> MessageContext would we even be receiving here? I think it would be
> clearer and cleaner to have all received messages, including faults, be
> handled by onMessage(), and then have onError() be explicitly for the
> case where something went wrong while sending. Alternately I'd be ok
> with separate onFault() and onError().
>
> So I'd propose the following:
>
> public interface Callback {
> /**
> * Received a message, info in the MessageContext. Might be a
> * fault, so check msgContext.isFault()!
> */
> void onMessage(MessageContext msgContext);
>
> /**
> * Operation is complete. (should we pass OperationContext?)
> */
> void onComplete();
>
> /**
> * Something went wrong on our side! The MessageContext
> * is the OUTGOING message. Incoming faults will trigger the
> * onMessage() callback above.
> */
> void onError(Exception e, MessageContext msgContext);
> }
>
> 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?
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.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [Axis2] org.apache.axis2.client.async.Callback#onError method
signature
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi dims!
Davanum Srinivas wrote:
> Does it make sense to change the method as follows? Basically add an
> extra paramter in onError?
>
> public abstract class Callback {
> public abstract void onComplete(AsyncResult result);
> public abstract void onError(Exception e, AsyncResult result);
> }
Hm... a couple of thoughts here.
First of all, is "onComplete()" really the right name for the callback?
If you have an MEP with multiple response messages, mightn't this get
called a few times? Perhaps onMessage() is better, and then we can have
onComplete() be a separate callback to indicate that the MEP is done.
Second, what's the point of AsyncResult? It contains nothing except a
MessageContext right now. Recommend dropping this class.
Third, why is Callback an abstract class and not just an interface?
There doesn't seem to be enough going on there (really just setting the
"complete" flag) to warrant the limitations that you get when extending
instead of implementing.
Fourth, if you get an onError(), does that mean you a) received a fault
message, or b) something went wrong on our side? In other words, which
MessageContext would we even be receiving here? I think it would be
clearer and cleaner to have all received messages, including faults, be
handled by onMessage(), and then have onError() be explicitly for the
case where something went wrong while sending. Alternately I'd be ok
with separate onFault() and onError().
So I'd propose the following:
public interface Callback {
/**
* Received a message, info in the MessageContext. Might be a
* fault, so check msgContext.isFault()!
*/
void onMessage(MessageContext msgContext);
/**
* Operation is complete. (should we pass OperationContext?)
*/
void onComplete();
/**
* Something went wrong on our side! The MessageContext
* is the OUTGOING message. Incoming faults will trigger the
* onMessage() callback above.
*/
void onError(Exception e, MessageContext msgContext);
}
Thoughts?
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org