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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
