| dave irving (JIRA) 2005-11-13, 7:45 am |
| [ http://issues.apache.org/jira/brows...action_12357520 ]
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 i
tself (and not client code).
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 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 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:
http://issues.apache.org/jira/secur...nistrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|