That's why I think we're going to want to have the ability to mine the config of a switchInterceptor. A given impl could inspect the config and say, oh this is a method name invocationmatcher; I'll eliminate a level and match the method directly to the consequent interceptor up front. For more dynamic, particularly user-specified, forms of args and other invocation matching you can of course only go so far. For these reasons I also think that in general these invocation matchers should be final so we can make assumptions about their behavior.
Matt On Thu, Aug 1, 2013 at 10:00 AM, James Carman <ja...@carmanconsulting.com>wrote: > 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 > >
