From dev-return-51010-apmail-cloudstack-dev-archive=cloudstack.apache.org@cloudstack.apache.org Tue Jan 28 19:07:12 2014 Return-Path: X-Original-To: apmail-cloudstack-dev-archive@www.apache.org Delivered-To: apmail-cloudstack-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8B51E10FA8 for ; Tue, 28 Jan 2014 19:07:12 +0000 (UTC) Received: (qmail 29217 invoked by uid 500); 28 Jan 2014 19:07:10 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 29128 invoked by uid 500); 28 Jan 2014 19:07:10 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 29119 invoked by uid 99); 28 Jan 2014 19:07:09 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Jan 2014 19:07:09 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of mike.tutkowski@solidfire.com designates 209.85.219.47 as permitted sender) Received: from [209.85.219.47] (HELO mail-oa0-f47.google.com) (209.85.219.47) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Jan 2014 19:07:03 +0000 Received: by mail-oa0-f47.google.com with SMTP id m1so911400oag.34 for ; Tue, 28 Jan 2014 11:06:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=0FyCwBLb3zvByb+1+1v5V+aAQV7fA8/hGKW8/TqUpyI=; b=cbCuXKMT081YyCe8I8IuK9wjPgoWU5ogiTibHUZxtcd+Zg82SWb3vC+8i6pKGxXb9s 0MrrvC65JkQZ+ceOKD5/tU6/eGO1pfGUkmB/uWQdOY162Y1djeSQXnz0wj/eUz6eh5I5 iBMMghRBF2NX7HlZQF9t6YaCPpBpM+hQpKKAH4eQEpeD4PNp03lI/ypuKm7/Gx8nGu3q hyveRGIpQ0dxUfOcLupP02RK0Wt92ep+t36FDvDNUXOn/wWK3kfO1dW2vSuWgY8EhgXI 19+pyFb+eZfXfEDPU9SjPO/p0EHUFDVOa0CUJWhNMRU7Y4dJQNiKzExtywbPLKQNQdVw 8jSw== X-Gm-Message-State: ALoCoQmKZyuHLXYwzsbhJvacVT96zyQZAFRvKlkNcmu8D/HdfsLiUKIwwKkEbcQQVBjCzlI0siko MIME-Version: 1.0 X-Received: by 10.182.128.138 with SMTP id no10mr2377459obb.32.1390936002776; Tue, 28 Jan 2014 11:06:42 -0800 (PST) Received: by 10.182.114.164 with HTTP; Tue, 28 Jan 2014 11:06:42 -0800 (PST) In-Reply-To: References: Date: Tue, 28 Jan 2014 12:06:42 -0700 Message-ID: Subject: Re: Callback pattern From: Mike Tutkowski To: "dev@cloudstack.apache.org" Content-Type: multipart/alternative; boundary=089e0153852e59e8c104f10c862e X-Virus-Checked: Checked by ClamAV on apache.org --089e0153852e59e8c104f10c862e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 wrote= : > Mike, > > This is a very dirty hack that I personally hate it. This is the hack to > utilize Eclipse=B9s (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 dynamicall= y > 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" > 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 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 > >* * > > --=20 *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkowski@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud *(tm)* --089e0153852e59e8c104f10c862e--