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
