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

Reply via email to