Inline On Thu, Sep 13, 2012 at 5:08 PM, Romain Manni-Bucau <[email protected]>wrote:
> right > > the question here is do we want to use it or not internally (cdi-query was > based on it no? and i think it avoid to repeat too much code, we could > handle the annotation indirection you speak about to be clearer in APIs) > > if we dont' want to use it, it can wait CDI-110 otherwise we can push it > now (maybe take servicehandler code but removing javassist?) > > i'm still not very clear about DS and its CDI targets: saw CDI 1.0 is a > target so maybe we should address it even if CDI 1.1 answer later to this > question...i'm not very concerned about it but it should be taken into > account i think DeltaSpike (as can be seen in our CI builds) targets current CDI 1.0 implementations and also being forward compatible with CDI 1.1 (as I believe Weld is the only one currently with a CDI 1.1 branch, could be wrong though). > *Romain Manni-Bucau* > *Twitter: @rmannibucau* > *Blog: http://rmannibucau.wordpress.com* > > > > > 2012/9/14 Stuart Douglas <[email protected]> > > > I suppose it depends on if https://issues.jboss.org/**browse/CDI-110< > 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< > 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< > http://rmannibucau.wordpress.com> > >> * > >> > >> > -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu
