Glad you already figured it out.
Removing generic is for purpose, since AsyncCallbackDispatcher sits at the
bottom of the chain that needs to deal with different kinds of callback
completion routines. Type-safe check for callback completion routine is
done through AsyncCompletionCall itself
publi
Cancel that query. :)
It looks like public class AsyncCallbackDispatcher implements
AsyncCompletionCallback
breaks a couple places in the codebase.
On Tue, Jan 28, 2014 at 11:56 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:
> Hi Kelven,
>
> Thanks for the info.
>
> Yeah, I figured i
Hi Kelven,
Thanks for the info.
Yeah, I figured it "appeared" to be over engineered in this regard because
there probably was (and possibly still is) a grander vision of where we'd
like to take CloudStack.
You know, on a related note, I noticed the following:
public class AsyncCallbackDispatche
Originally we did think to introduce async model to CloudStack
orchestration engine, using queues, event notifications etc to make the
system more loosely-coupled and use much less thread resources with async
programming. However, due the large code base we already have and
synchronous programming
It seems in the cases that I've observed this pattern that we don't
actually do anything asynchronously. We call a method that has the word
"Async" in it typically, but this method does everything in sequence and
then returns a "future" object. The calling code then calls get() on the
future object
I originally thought to just ask developer to use plain string literals,
it has better readability but it can’t take advantage of IDE provided
refactoring (callback method renames), it ended up to this crazy approach.
Hopefully one day Java may provide C# delegate like feature, then all
these hacki
I see...just for chaining purposes. In some places I notice we chain this
and in others we don't.
Thanks for the clarification!
On Tue, Jan 28, 2014 at 3:13 PM, Kelven Yang wrote:
> This is to support fluent coding style to chain all the callback setup
> calls in one line. Using caller.getTarg
This is to support fluent coding style to chain all the callback setup
calls in one line. Using caller.getTarget().callbackMethod() alone may
cause people to think the statement as a logic requirement and actually it
is not but hackings.
It is like to setup a function pointer in C or delegate in C
Thanks Kelven
Yeah, that code is pretty crazy. :)
I followed that the getTarget() method actually dynamically extends a class
and allows us to inject logic in the new class that enables us to save
createVolumeFromBaseImageCallBack as the method we want to invoke when our
async operation has compl
Mike,
This is a very dirty hack that I personally hate it. This is the hack to
utilize Eclipse¹s (or other smart IDE) to do auto-completion for you to
find the right callback method.
if you write
caller.getTarget().createVolumeFromBaseImageCallBack(null, null);
Java will interprete it as a
10 matches
Mail list logo