You're going to lose the benefit of having ASM if you just end up using reflection to call the methods anyway aren't you? The Javassist code actually generates Java code that actually calls the real method on an instance of the appropriate type. That's what makes it faster.
On Thu, Aug 1, 2013 at 10:57 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > No, but believe me you want a handler (this one or invoker) to maintain the > code and keep it easy. > > *Romain Manni-Bucau* > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* > *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* > *Github: https://github.com/rmannibucau* > > > > 2013/8/1 Matt Benson <gudnabr...@gmail.com> > >> That's my point; it doesn't. >> >> >> On Thu, Aug 1, 2013 at 9:49 AM, James Carman <ja...@carmanconsulting.com >> >wrote: >> >> > Does the ASM API require a java.lang.reflect.InvocationHandler? >> > >> > On Thu, Aug 1, 2013 at 10:41 AM, Romain Manni-Bucau >> > <rmannibu...@gmail.com> wrote: >> > > Well for the maintainance it is easier (and not really slower) to use a >> > > little abstraction. InvocationHandler/Inoker is fine. Since JdkProxy >> uses >> > > the exact same code i throught it could be shared. >> > > >> > > *Romain Manni-Bucau* >> > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >> > > *Blog: **http://rmannibucau.wordpress.com/*< >> > http://rmannibucau.wordpress.com/> >> > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >> > > *Github: https://github.com/rmannibucau* >> > > >> > > >> > > >> > > 2013/8/1 Matt Benson <gudnabr...@gmail.com> >> > > >> > >> The behavior of proxies is specified by Invokers, ObjectProviders, and >> > >> Interceptors. Each ProxyFactory implementation bridges from these >> > >> interfaces to the most appropriate mechanism specific to the target >> > >> technology. In the case of ASM, I would think that would be direct >> calls >> > >> against the proxy interface implementations themselves. >> > >> >> > >> Matt >> > >> On Aug 1, 2013 9:21 AM, "Romain Manni-Bucau" <rmannibu...@gmail.com> >> > >> wrote: >> > >> >> > >>> a sed shold almost work but the issue is the same: the code is >> > >>> duplicated, no? is there invoker elsewhere? >> > >>> >> > >>> *Romain Manni-Bucau* >> > >>> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >> > >>> *Blog: **http://rmannibucau.wordpress.com/*< >> > http://rmannibucau.wordpress.com/> >> > >>> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >> > >>> *Github: https://github.com/rmannibucau* >> > >>> >> > >>> >> > >>> >> > >>> 2013/8/1 Matt Benson <gudnabr...@gmail.com> >> > >>> >> > >>>> But is there some technical reason why it's helpful for ASM proxies >> to >> > >>>> use >> > >>>> InvocationHandler specifically? Why wouldn't they just use Invoker >> > >>>> directly? >> > >>>> >> > >>>> Matt >> > >>>> >> > >>>> >> > >>>> On Thu, Aug 1, 2013 at 8:51 AM, Romain Manni-Bucau < >> > >>>> rmannibu...@gmail.com>wrote: >> > >>>> >> > >>>> > +1 >> > >>>> > >> > >>>> > jdkproxyfactory can even be hardcoded as a default IMO (without >> > using >> > >>>> the >> > >>>> > SPI) >> > >>>> > >> > >>>> > >> > >>>> > *Romain Manni-Bucau* >> > >>>> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >> > >>>> > *Blog: **http://rmannibucau.wordpress.com/*< >> > >>>> > http://rmannibucau.wordpress.com/> >> > >>>> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >> > >>>> > *Github: https://github.com/rmannibucau* >> > >>>> > >> > >>>> > >> > >>>> > >> > >>>> > 2013/8/1 James Carman <ja...@carmanconsulting.com> >> > >>>> > >> > >>>> > > You mean all the InvocationHandler classes in JdkProxy? I guess >> > we >> > >>>> > > could break those out into top-level classes, but then you'd >> have >> > >>>> > > multiple implementations on your classpath if you made a >> > dependency >> > >>>> on >> > >>>> > > commons-proxy-jdk. We could move those to "core" I guess. >> > >>>> > > >> > >>>> > > On Thu, Aug 1, 2013 at 7:49 AM, Romain Manni-Bucau >> > >>>> > > <rmannibu...@gmail.com> wrote: >> > >>>> > > > Ok for all excepted last point (i was not clear i think). The >> > >>>> > > ProxyFactory >> > >>>> > > > impl using jdk proxy uses Invocationhandler like the asm >> > >>>> implementation >> > >>>> > > so >> > >>>> > > > it would be great to be able to share the handler classes >> > between >> > >>>> both >> > >>>> > > impl. >> > >>>> > > > >> > >>>> > > > *Romain Manni-Bucau* >> > >>>> > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >> > >>>> > > > *Blog: **http://rmannibucau.wordpress.com/*< >> > >>>> > > http://rmannibucau.wordpress.com/> >> > >>>> > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >> > >>>> > > > *Github: https://github.com/rmannibucau* >> > >>>> > > > >> > >>>> > > > >> > >>>> > > > >> > >>>> > > > 2013/8/1 James Carman <ja...@carmanconsulting.com> >> > >>>> > > > >> > >>>> > > >> On Thu, Aug 1, 2013 at 2:44 AM, Romain Manni-Bucau >> > >>>> > > >> <rmannibu...@gmail.com> wrote: >> > >>>> > > >> > ok, >> > >>>> > > >> > >> > >>>> > > >> > here it is: https://gist.github.com/rmannibucau/6128964 >> > >>>> > > >> > >> > >>>> > > >> >> > >>>> > > >> Thanks! >> > >>>> > > >> >> > >>>> > > >> > >> > >>>> > > >> > 1) i didn't fully get the goal of stub module, any >> pointers? >> > >>>> > > >> >> > >>>> > > >> It provides features very similar to the mocking support in >> > >>>> libraries >> > >>>> > > >> like Mockito/EasyMock. Basically, you can "train" a proxy to >> > do >> > >>>> what >> > >>>> > > >> you want in certain situations. >> > >>>> > > >> >> > >>>> > > >> > 2) in ProxyFactory methods have this kind of signature >> > >>>> > > >> > >> > >>>> > > >> > <T> T createDelegatorProxy( ClassLoader classLoader, >> > >>>> > ObjectProvider<?> >> > >>>> > > >> > delegateProvider, >> > >>>> > > >> > Class<?>... >> > >>>> proxyClasses ); >> > >>>> > > >> > >> > >>>> > > >> > why <T>if ObjectProvider is not ObjectProvider<T> (same for >> > >>>> Object >> > >>>> > for >> > >>>> > > >> > others method). basically T isn't matched. >> > >>>> > > >> > >> > >>>> > > >> >> > >>>> > > >> I'll have to take a look. I believe the <T> is there for >> > >>>> "syntactic >> > >>>> > > >> sugar", since you can pass in any classes you want really. >> > >>>> Hopefully >> > >>>> > > >> the user won't do something stupid and they'll actually pass >> > >>>> Class<T> >> > >>>> > > >> as one of the proxyClasses when they're asking for a return >> > type >> > >>>> of >> > >>>> > > >> <T> back. Since you can have multiple proxy classes, the >> > >>>> > > >> ObjectProvider can't really match any one particular one (it >> > >>>> needs to >> > >>>> > > >> support all). >> > >>>> > > >> >> > >>>> > > >> > 3) the jdk implementation uses InvocationHandler for the >> > >>>> proxying, >> > >>>> > asm >> > >>>> > > >> > implementation has almost the same (i didn't check but i >> > started >> > >>>> > from >> > >>>> > > an >> > >>>> > > >> > exact copy), it would be great to get them in a common >> > module to >> > >>>> > > avoid to >> > >>>> > > >> > duplicate it >> > >>>> > > >> > >> > >>>> > > >> >> > >>>> > > >> We have our own interface for InvocationHander, it's called >> > >>>> Invoker. >> > >>>> > > >> Other libraries can be "adapted" to ours if you want to reuse >> > >>>> > > >> something. >> > >>>> > > >> >> > >>>> > > >> >> > >>>> >> --------------------------------------------------------------------- >> > >>>> > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > >>>> > > >> For additional commands, e-mail: dev-h...@commons.apache.org >> > >>>> > > >> >> > >>>> > > >> >> > >>>> > > >> > >>>> > > >> > --------------------------------------------------------------------- >> > >>>> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > >>>> > > For additional commands, e-mail: dev-h...@commons.apache.org >> > >>>> > > >> > >>>> > > >> > >>>> > >> > >>>> >> > >>> >> > >>> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
