Which code are you worried about? The checking for equals/hashcode? On Thu, Aug 1, 2013 at 10: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
