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 >>> > > >>> > > >>> > >>> >> >>
