Well that s the current status but the point is do we add feature to (the last release) of cdi or do we keep a compatibility with old version (i prefer the 1st one but understand the 2nd)
About javassist David Blevins is working on sthg close for owb which could go to commons IMO. Le 14 sept. 2012 02:02, "Jason Porter" <[email protected]> a écrit : > 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 >
