Oleksiy:
The issue 673 related to this topic was created and assigned to you. Meanwhile, I am working on this issue from my side.
Ming Qin
--- On Tue, 6/16/09, Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM> wrote:
From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Subject: Re: Should notificationObject be Instance of Future in Grizzly 2.0?
To: dev_at_grizzly.dev.java.net
Date: Tuesday, June 16, 2009, 5:50 AM
Hi Ming,
good catch, this class was moved from 1.9.x branch, and for sure could be improved by using Future and CompletionHandler abstractions instead of Callable, Runnable etc.Please file the issue, I'll get to it asap, or any patch from your side will be also very appreciated :)
Thank you.
WBR,Alexey.
On Jun 15, 2009, at 23:31 , ming qin wrote:
Grizzly 2.0 framework( grizzly-framework) API is based on java.util.concurrent.Future. In release 2.0.0-M3, only one class ( com.sun.grizzly.utils.conditions.DefaultConditionListener) is referring java.util.concurrent.Callable( another is Junit test class- AsyncWriteQueueTest.java).
Since there are no other classes referring Callable except DefaultConditionListener itself in whole grizzly-framework API, doesn't nofiyListernObject method need care about noticationObject as instance of Callable?
Below is notifyListenerObject method,
public static final void notifyListenerObject(Object notificationObject) { if (notificationObject instanceof CountDownLatch) { …. } else if (notificationObject instanceof Callable) { ……. } } else if (notificationObject instanceof Runnable) { ……… } else { synchronized (notificationObject) { notificationObject.notify(); } } }
Ming Qin
Cell Phone 858-353-2839