cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: Callback pattern
Date Tue, 28 Jan 2014 19:06:42 GMT
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 completed.

It does provide the benefit that you don't have to pass in a string that
represents the method name.

What I was actually wondering about, though, is why we surround
caller.getTarget().createVolumeFromBaseImageCallBack(null, null); with
caller.setCallback();?

It seems that setCallback() ignores the input parameter and just returns
"this";

Wouldn't caller.getTarget().createVolumeFromBaseImageCallBack(null, null);
by itself work exactly the same way?


On Tue, Jan 28, 2014 at 11:57 AM, Kelven Yang <kelven.yang@citrix.com>wrote:

> 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 standalone method call,
>
>
> If you write as below, it tries to tell that this is to setup a callback,
> to return this in caller.setCallback is to let you continue to use fluent
> style to callback setups
>
>     caller.setCallback(
> caller.getTarget().createVolumeFromBaseImageCallBack(null, null) );,
>
> Behind scene, it uses CGLIB for dispatcher to figure out which method is
> the callback without requiring developer to give it as literal string
>
>
> AsyncMethod pattern is used commonly in parallel algorithms to dynamically
> branch out sub-calculations, I think it does not fit well in CloudStack,
> and also due to the lack of language feature in Java,   this hacking
> technique makes the code really hard to read
>
> Kelven
>
> On 1/27/14, 6:55 PM, "Mike Tutkowski" <mike.tutkowski@solidfire.com>
> wrote:
>
> >Hi,
> >
> >I've been looking at our callback pattern.
> >
> >Can someone explain why we always seem to do this?:
> >
> >caller.setCallback(caller.getTarget().createVolumeFromBaseImageCallBack(nu
> >ll,
> >null));
> >
> >When setCallback is implemented like this:
> >
> >public AsyncCallbackDispatcher<T, R> setCallback(Object useless) {
> >
> >    return this;
> >
> > }
> >
> >Why not just this?:
> >
> >caller.getTarget().createVolumeFromBaseImageCallBack(null, null);
> >
> >Thanks!
> >
> >--
> >*Mike Tutkowski*
> >*Senior CloudStack Developer, SolidFire Inc.*
> >e: mike.tutkowski@solidfire.com
> >o: 303.746.7302
> >Advancing the way the world uses the
> >cloud<http://solidfire.com/solution/overview/?video=play>
> >* *
>
>


-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message