Return-Path: X-Original-To: apmail-incubator-deltaspike-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-deltaspike-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BA63ADC2A for ; Thu, 13 Sep 2012 22:56:16 +0000 (UTC) Received: (qmail 59567 invoked by uid 500); 13 Sep 2012 22:56:16 -0000 Delivered-To: apmail-incubator-deltaspike-dev-archive@incubator.apache.org Received: (qmail 59539 invoked by uid 500); 13 Sep 2012 22:56:16 -0000 Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: deltaspike-dev@incubator.apache.org Delivered-To: mailing list deltaspike-dev@incubator.apache.org Received: (qmail 59529 invoked by uid 99); 13 Sep 2012 22:56:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Sep 2012 22:56:16 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sdouglas@redhat.com designates 209.132.183.28 as permitted sender) Received: from [209.132.183.28] (HELO mx1.redhat.com) (209.132.183.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Sep 2012 22:56:11 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q8DMtoCl023383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 13 Sep 2012 18:55:50 -0400 Received: from Stuarts-iMac.local (vpn-8-209.rdu.redhat.com [10.11.8.209]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q8DMtJi9029921 for ; Thu, 13 Sep 2012 18:55:35 -0400 Message-ID: <50526450.4050902@redhat.com> Date: Fri, 14 Sep 2012 08:55:12 +1000 From: Stuart Douglas User-Agent: Postbox 3.0.5 (Macintosh/20120826) MIME-Version: 1.0 To: deltaspike-dev@incubator.apache.org Subject: Re: @Proxy References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Virus-Checked: Checked by ClamAV on apache.org I suppose it depends on if https://issues.jboss.org/browse/CDI-110 makes it into the specification. This sounds equivalent to the solder @ServiceHandler annotation, although @ServiceHandler has another layer of indirection, so you do not need to specify the implementation class directly on the bean. I think this is a useful feature. Stuart Romain Manni-Bucau wrote: > Hi, > > wonder if we want the "already bridged proxy feature" (i'll explain don't > worry ;)). > > There are cases where the implementation is boring and pretty obvious and > defining an interface has the benefit to creates a semantic but the > implementation itself is pretty useless (ex: spring-data, cdi-query, ...) > > We can of course do "as usually" and create proxy for all features needing > it specifically. > > However i think this proxy feature is generic enough and could be pushed to > the user if he wants to do so. > > Here some functional cases i think about which could use this feature: > 1) (already cited) a cdi-query like > 2) accessing JMX information (locally or not) without needed to use JMX API > ( > http://svn.apache.org/repos/asf/openejb/trunk/openejb/examples/dynamic-proxy-to-access-mbean/src/test/java/org/superbiz/dynamic/mbean/DynamicMBeanClient.java > for > instance) > 3) creating a rest api easily from method name (getUserList -> GET > /user/list for instance) > 4) .... > > it can go further allowing multiple handlers by interface > > wdyt? > > *Romain Manni-Bucau* > *Twitter: @rmannibucau* > *Blog: http://rmannibucau.wordpress.com* >