[ http://issues.apache.org/jira/brows...23575
20 ]

dave irving commented on DIRMINA-120:
-------------------------------------

> Providing two methods by default, I think we don't need to add ConnectList
ener
> or other possible listeners IMHO though this will cause an inevitable downcasting.
 WDYT?

Yeah - makes sense.
I started out with doing it the "operationSucceeded" / "operationFailed" way
 in IoFuture. Then I had a look at the existing implementations (write, clos
e) and there didn't seem to be a common "failure" possibility.
So the down side of having a common failure case in the callback seemed to b
e that each (client) implementation would have to implement operationFailed 
- even though it wouldn't ever be called.

Having the base callback just having "operationCompleted" meant that the fut
ures themselves could add any extra meaning to this if desired, but wouldn't
 require client code to do so. Any downcasting is limited to the implementat
ion details of the future i
tself (and not client code).

I guess its a trade off :o) If we dont mind all client Callback implementati
ons having to implement operationFailed when it wont ever be called - then t
his is definately a cleaner approach.

Dave

> Callbacks for IoFutures
> -----------------------
>
>          Key: DIRMINA-120
>          URL: http://issues.apache.org/jira/browse/DIRMINA-120
>      Project: Directory MINA
>         Type: Improvement
>     Reporter: Trustin Lee
>     Assignee: Trustin Lee
>      Fix For: 0.9
>  Attachments: ConnectFuture.java, IoFuture.java
>
> IoFuture provides only blocking-way ('join' method) for user to find out t
he result of an I/O request.  It would be great if users can specify a callb
ack:
> ConnectFuture future = connector.connect(...);
> future.setCallback( new ConnectFuture.Callback() {
>     public void connectionEstablished( IoSession session ) {
>     }
>     public void connectionFailed( Throwable cause ) {
>     }
> } );
> There can be a race condition if the connection process ends before a user calls s
etCallback() method, but we can resolve this carefully so users don't notice any iss
ue.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secur...nistrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

[ Post a follow-up to this message ]