Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <463F3031.7020302@thoughtcraft.com>
Date: Mon, 07 May 2007 09:57:05 -0400
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: axis-dev@ws.apache.org
Subject: Re: [Axis2] org.apache.axis2.client.async.Callback#onError method
	signature
References: <19e0530f0705070634i525bf0e0j8a86cdb3f65e2b7c@mail.gmail.com>
In-Reply-To: <19e0530f0705070634i525bf0e0j8a86cdb3f65e2b7c@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
From: Glen Daniels <glen@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