directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "dave irving (JIRA)" <>
Subject [jira] Commented: (DIRMINA-120) Callbacks for IoFutures
Date Sun, 13 Nov 2005 12:04:23 GMT
    [ ] 

dave irving commented on DIRMINA-120:

> Providing two methods by default, I think we don't need to add ConnectListener 
> 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, close) 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 be 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 futures 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 implementation details of the future itself (and not client

I guess its a trade off :o) If we dont mind all client Callback implementations having to
implement operationFailed when it wont ever be called - then this is definately a cleaner


> Callbacks for IoFutures
> -----------------------
>          Key: DIRMINA-120
>          URL:
>      Project: Directory MINA
>         Type: Improvement
>     Reporter: Trustin Lee
>     Assignee: Trustin Lee
>      Fix For: 0.9
>  Attachments:,
> IoFuture provides only blocking-way ('join' method) for user to find out the result of
an I/O request.  It would be great if users can specify a callback:
> 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 setCallback()
method, but we can resolve this carefully so users don't notice any issue.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message