Re: Callback pattern

2014-01-29 Thread Kelven Yang
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

Re: Callback pattern

2014-01-28 Thread Mike Tutkowski
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

Re: Callback pattern

2014-01-28 Thread Mike Tutkowski
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

Re: Callback pattern

2014-01-28 Thread Kelven Yang
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

Re: Callback pattern

2014-01-28 Thread Mike Tutkowski
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

Re: Callback pattern

2014-01-28 Thread Kelven Yang
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

Re: Callback pattern

2014-01-28 Thread Mike Tutkowski
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

Re: Callback pattern

2014-01-28 Thread Kelven Yang
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

Re: Callback pattern

2014-01-28 Thread Mike Tutkowski
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

Re: Callback pattern

2014-01-28 Thread Kelven Yang
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