You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2013/07/27 15:51:27 UTC
[proxy] and impl
Hi
On a mail on [monitoring] i put some point on proxy. The main question was
shouldnt proxy give a default impl of proxying instead of being a facade
(which needs to put all impl specifities in the api or a way to get them)?
In tomee/openejb and owb we use asm to create proxies and InvocationHandler
standard interface. That's very powerful and insanely fast.
Asm also provides some helpers like
http://asm.ow2.org/asm40/javadoc/user/org/objectweb/asm/commons/AdviceAdapter.html.
My question is then: shouldnt proxy2 change a bit of spirit?
Re: [proxy] and impl
Posted by Matt Benson <gu...@gmail.com>.
Nice... this would probably be enough, dependency-wise, IMO, until someone
actually has a need for something else.
Matt
On Wed, Jul 31, 2013 at 2:07 PM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> Hi
>
> here is the asm4-shaded impl: https://gist.github.com/rmannibucau/6125125
>
> *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/7/29 Romain Manni-Bucau <rm...@gmail.com>
>
>> hmm not sure i follow, here we don't shade asm (it is already done) and
>> if all libs shade it we will have at least 5 shade of the same version in
>> tomee for instance (same comment on the app side) so that's not a solution
>> for each lib. [proxy] is small enough to not shade IMO. That said if your
>> relocation trick works it would be enough to copy classes with relocation
>> in 3-4 places.
>>
>> *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/7/29 Matt Benson <gu...@gmail.com>
>>
>>> Rather than duplicating code I thought we could code to asm4's released
>>> jars, and provide the basic proxy-asm artifact. Then shade asm4 and
>>> provide proxy-asm-shaded. Then optionally, we could create another shaded
>>> jar that relocates to the same destination as xbean-shaded-asm4 but does
>>> not actually shade the classes. I think maven-shade-plugin would do this
>>> by specifying relocations without the artifactSet, though I haven't tried
>>> it. Then we support:
>>>
>>> * asm4 is on classpath
>>> * one well-known shading that the user may already have on the classpath
>>> * dependencies shaded to a namespace specific to proxy-asm
>>>
>>> One of these options will work in every case. Even ASM's own FAQ
>>> recommends the equivalent of shading per consuming library[1].
>>>
>>> Matt
>>>
>>> [1] http://asm.ow2.org/doc/faq.html#Q15
>>>
>>>
>>> On Mon, Jul 29, 2013 at 9:59 AM, Romain Manni-Bucau <
>>> rmannibucau@gmail.com> wrote:
>>>
>>>> You have the clean proxy code here (just rework the method generation
>>>> which is a bit different):
>>>> http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/util/proxy/LocalBeanProxyFactory.java
>>>>
>>>> the point is i already have cases where i want to use asm and asm
>>>> shaded, we can multiply the impl number too but it would duplicate the code.
>>>>
>>>> About the perf a bench would say it, i didn't take time to do it.
>>>>
>>>> *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/7/29 Matt Benson <gu...@gmail.com>
>>>>
>>>>>
>>>>> On Sun, Jul 28, 2013 at 12:16 PM, Romain Manni-Bucau <
>>>>> rmannibucau@gmail.com> wrote:
>>>>>
>>>>>> answers inline
>>>>>>
>>>>>> *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/7/28 Matt Benson <gu...@gmail.com>
>>>>>>
>>>>>>> Interesting patch. I have some questions and comments:
>>>>>>>
>>>>>>> - You'd additionally need to make sure the impl class is non-final,
>>>>>>> no?
>>>>>>>
>>>>>>
>>>>>> hmm, good question i didn't check but with asm we can subclass final
>>>>>> classes, hehe
>>>>>>
>>>>>
>>>>>
>>>>> We can? How devious... well, then strike my question.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>> - note to others that asm4-shaded is used because asm didn't change
>>>>>>> packages from v3. Good to see this in use; I hadn't kept track after
>>>>>>> submitting that patch. ;-)
>>>>>>>
>>>>>>
>>>>>> i used asm4 since that's the more up to date and it supports java 7
>>>>>> very well. The shade was used since provided in tomee and owb but real asm
>>>>>> should be fine (see next point)
>>>>>>
>>>>>>
>>>>>>> - Would you explain the purpose of the AsmFacade class? Much of the
>>>>>>> "nuts and bolts" work of the patch seems quite different from what I
>>>>>>> perceive as "typical asm client code."
>>>>>>>
>>>>>>
>>>>>> i first wrote it with asm imports but a common issue is: do i use
>>>>>> asm? spring-asm-shade? xbean-asm-shade? so AsmFacade is an utility class to
>>>>>> allow to use whatever impl is here (almost).
>>>>>>
>>>>>>
>>>>>
>>>>> While I find this to be interesting and quite clever, I feel like it's
>>>>> maybe too much. For one point, have you tried searching the web for
>>>>> meaningful examples of ASM code? It's not that easy IMO. I think it'd be
>>>>> nicer for our ASM code to exemplify "normal" ASM as much as possible. I'd
>>>>> say it'd be enough to write the basic impl against stock asm4. If we
>>>>> wanted we could then provide one artifact that shades asm4, and another
>>>>> that rewrites the compiled classes to depend on xbean-shaded-asm4, and
>>>>> surely that would be enough for users to get by with. Then our code would
>>>>> be more intelligible as well as useful from the perspective of helping
>>>>> other devs learn from good examples.
>>>>>
>>>>> Back to the subject of cglib, do you expect this implementation should
>>>>>>> significantly outperform it for any reason ( if so, which? ), or is the
>>>>>>> main motivation that cglib is almost dead as you say?
>>>>>>>
>>>>>>
>>>>>> since cglib is dead we need something else and i expect the impl to
>>>>>> be faster than javassist. Another nice side effect is no dep in a container
>>>>>> providing asm.
>>>>>>
>>>>>>
>>>>>
>>>>> I am taking this as still saying, yes, the ASM proxy implementation
>>>>> might not be any faster than cglib. ;) Which is fine.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Matt
>>>>>
>>>>>
>>>>>> Thanks and regards,
>>>>>>> Matt
>>>>>>> On Jul 28, 2013 10:58 AM, "Romain Manni-Bucau" <
>>>>>>> rmannibucau@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> here is a patch implementing proxying using ASM:
>>>>>>>> https://gist.github.com/rmannibucau/6099063
>>>>>>>>
>>>>>>>> having the handlers used by default in ProxyFactory protected would
>>>>>>>> avoid to copy them in ASMProxyFactory.
>>>>>>>>
>>>>>>>> *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/7/28 Romain Manni-Bucau <rm...@gmail.com>
>>>>>>>>
>>>>>>>>> Cglib is "almost" dead if i'm right, javassist is alive but not
>>>>>>>>> that stable and owb is faster ATM and at least would bring an Apache impl
>>>>>>>>> adapted to [proxy].
>>>>>>>>>
>>>>>>>>> Note: the fact to be able to reuse InvocationHandler and not a new
>>>>>>>>> API is great too
>>>>>>>>> Le 27 juil. 2013 20:13, "Matt Benson" <gu...@gmail.com> a
>>>>>>>>> écrit :
>>>>>>>>>
>>>>>>>>> AFAIK Mark Struberg's work on the OWB proxies could be
>>>>>>>>>> instructive, and
>>>>>>>>>> since I've just spent several weeks in ASM hell I might just be a
>>>>>>>>>> bit of
>>>>>>>>>> use there myself. The only thing is, isn't cglib built on ASM as
>>>>>>>>>> well? The
>>>>>>>>>> dynamic nature of the various proxy helpers means that we
>>>>>>>>>> probably couldn't
>>>>>>>>>> really improve on cglib, i.e. only if we could test invocation
>>>>>>>>>> matching up
>>>>>>>>>> front while creating the proxy class would we be faster.
>>>>>>>>>>
>>>>>>>>>> Matt
>>>>>>>>>> On Jul 27, 2013 12:22 PM, "Romain Manni-Bucau" <
>>>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> > Hehe, we benched in owb but lets wait the porting ;)
>>>>>>>>>> > Le 27 juil. 2013 16:49, "James Carman" <
>>>>>>>>>> james@carmanconsulting.com> a
>>>>>>>>>> > écrit :
>>>>>>>>>> >
>>>>>>>>>> > > On Sat, Jul 27, 2013 at 10:34 AM, Romain Manni-Bucau
>>>>>>>>>> > > <rm...@gmail.com> wrote:
>>>>>>>>>> > > > Once ill have done the monitoring stuff ill try to work on
>>>>>>>>>> it.
>>>>>>>>>> > >
>>>>>>>>>> > > What would be really cool is to have a "smackdown" once we
>>>>>>>>>> get ASM
>>>>>>>>>> > > into the mix to see which one performs the best and exactly
>>>>>>>>>> how fast
>>>>>>>>>> > > they are compared to one another.
>>>>>>>>>> > >
>>>>>>>>>> > >
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>> > > For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>> > >
>>>>>>>>>> > >
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [proxy] and impl
Posted by James Carman <ja...@carmanconsulting.com>.
Which code are you worried about? The checking for equals/hashcode?
On Thu, Aug 1, 2013 at 10:21 AM, Romain Manni-Bucau
<rm...@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 <gu...@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 <rmannibucau@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
>> > > <rm...@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
>> > > >> <rm...@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-unsubscribe@commons.apache.org
>> > > >> For additional commands, e-mail: dev-help@commons.apache.org
>> > > >>
>> > > >>
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > > For additional commands, e-mail: dev-help@commons.apache.org
>> > >
>> > >
>> >
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [proxy] and impl
Posted by Romain Manni-Bucau <rm...@gmail.com>.
can you add asm and run benchmark 10 times?
*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>
> This is rudimentary off the top of my head, but the following code
> produces this output:
>
> It took a total of 9.022382 seconds using $Proxy0.
> It took a total of 5.528322 seconds using
> TestAnnotationTrainer$Foo$$EnhancerByCGLIB$$c462c19e.
> It took a total of 5.084160 seconds using JavassistUtilsGenerated_1.
>
> I'm sure it's not the most scientific, but it's a start.
>
> private static void benchmark(Foo[] foos, long n)
> {
> final long totals[] = new long[foos.length];
> for (int count = 0; count < n; ++count)
> {
> for (int i = 0; i < foos.length; i++)
> {
> Foo foo = foos[i];
> final long before = System.nanoTime();
> for (int j = 0; j < 10000; ++j)
> {
> foo.bar();
> }
> totals[i] += System.nanoTime() - before;
> }
> }
> for (int i = 0; i < foos.length; i++)
> {
> Foo foo = foos[i];
> System.out.println(String.format("It took a total of %f
> seconds using %s.", totals[i] / 1000000000.0,
> foo.getClass().getSimpleName()));
> }
> }
>
>
> //----------------------------------------------------------------------------------------------------------------------
> // Inner Classes
>
> //----------------------------------------------------------------------------------------------------------------------
>
> public static interface Foo
> {
> public void bar();
> }
>
> public static class FooImpl implements Foo
> {
> @Override
> public void bar()
> {
>
> }
> }
>
>
> //----------------------------------------------------------------------------------------------------------------------
> // main() method
>
> //----------------------------------------------------------------------------------------------------------------------
>
> public static void main(String[] args)
> {
> CglibProxyFactory cglib = new CglibProxyFactory();
> JdkProxyFactory jdk = new JdkProxyFactory();
> JavassistProxyFactory javassist = new JavassistProxyFactory();
> ObjectProvider<Foo> provider =
> ObjectProviderUtils.<Foo>constant(new FooImpl());
> Foo cglibFoo = cglib.createDelegatorProxy(provider, Foo.class);
> Foo jdkFoo = jdk.createDelegatorProxy(provider, Foo.class);
> Foo javassistFoo = javassist.createDelegatorProxy(provider,
> Foo.class);
>
> final Foo[] foos = new Foo[]{jdkFoo, cglibFoo, javassistFoo};
>
> benchmark(foos, 100000);
>
>
> }
> }
>
> On Thu, Aug 1, 2013 at 11:15 AM, Romain Manni-Bucau
> <rm...@gmail.com> wrote:
> > hehe, do you have figures?
> >
> > when JIT did its work reflection is almost free. You can update the asm
> > proxy factory to handle 3 implementations but it is not worth it IMO
> >
> > *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'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
> >> <rm...@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 <gu...@gmail.com>
> >> >
> >> >> That's my point; it doesn't.
> >> >>
> >> >>
> >> >> On Thu, Aug 1, 2013 at 9:49 AM, James Carman <
> >> james@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
> >> >> > <rm...@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 <gu...@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" <
> >> rmannibucau@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 <gu...@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 <
> >> >> > >>>> rmannibucau@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
> >> >> > >>>> > > <rm...@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
> >> >> > >>>> > > >> <rm...@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-unsubscribe@commons.apache.org
> >> >> > >>>> > > >> For additional commands, e-mail:
> >> dev-help@commons.apache.org
> >> >> > >>>> > > >>
> >> >> > >>>> > > >>
> >> >> > >>>> > >
> >> >> > >>>> > >
> >> >> >
> ---------------------------------------------------------------------
> >> >> > >>>> > > To unsubscribe, e-mail:
> dev-unsubscribe@commons.apache.org
> >> >> > >>>> > > For additional commands, e-mail:
> dev-help@commons.apache.org
> >> >> > >>>> > >
> >> >> > >>>> > >
> >> >> > >>>> >
> >> >> > >>>>
> >> >> > >>>
> >> >> > >>>
> >> >> >
> >> >> >
> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >> > For additional commands, e-mail: dev-help@commons.apache.org
> >> >> >
> >> >> >
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [proxy] and impl
Posted by James Carman <ja...@carmanconsulting.com>.
This is rudimentary off the top of my head, but the following code
produces this output:
It took a total of 9.022382 seconds using $Proxy0.
It took a total of 5.528322 seconds using
TestAnnotationTrainer$Foo$$EnhancerByCGLIB$$c462c19e.
It took a total of 5.084160 seconds using JavassistUtilsGenerated_1.
I'm sure it's not the most scientific, but it's a start.
private static void benchmark(Foo[] foos, long n)
{
final long totals[] = new long[foos.length];
for (int count = 0; count < n; ++count)
{
for (int i = 0; i < foos.length; i++)
{
Foo foo = foos[i];
final long before = System.nanoTime();
for (int j = 0; j < 10000; ++j)
{
foo.bar();
}
totals[i] += System.nanoTime() - before;
}
}
for (int i = 0; i < foos.length; i++)
{
Foo foo = foos[i];
System.out.println(String.format("It took a total of %f
seconds using %s.", totals[i] / 1000000000.0,
foo.getClass().getSimpleName()));
}
}
//----------------------------------------------------------------------------------------------------------------------
// Inner Classes
//----------------------------------------------------------------------------------------------------------------------
public static interface Foo
{
public void bar();
}
public static class FooImpl implements Foo
{
@Override
public void bar()
{
}
}
//----------------------------------------------------------------------------------------------------------------------
// main() method
//----------------------------------------------------------------------------------------------------------------------
public static void main(String[] args)
{
CglibProxyFactory cglib = new CglibProxyFactory();
JdkProxyFactory jdk = new JdkProxyFactory();
JavassistProxyFactory javassist = new JavassistProxyFactory();
ObjectProvider<Foo> provider =
ObjectProviderUtils.<Foo>constant(new FooImpl());
Foo cglibFoo = cglib.createDelegatorProxy(provider, Foo.class);
Foo jdkFoo = jdk.createDelegatorProxy(provider, Foo.class);
Foo javassistFoo = javassist.createDelegatorProxy(provider, Foo.class);
final Foo[] foos = new Foo[]{jdkFoo, cglibFoo, javassistFoo};
benchmark(foos, 100000);
}
}
On Thu, Aug 1, 2013 at 11:15 AM, Romain Manni-Bucau
<rm...@gmail.com> wrote:
> hehe, do you have figures?
>
> when JIT did its work reflection is almost free. You can update the asm
> proxy factory to handle 3 implementations but it is not worth it IMO
>
> *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'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
>> <rm...@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 <gu...@gmail.com>
>> >
>> >> That's my point; it doesn't.
>> >>
>> >>
>> >> On Thu, Aug 1, 2013 at 9:49 AM, James Carman <
>> james@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
>> >> > <rm...@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 <gu...@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" <
>> rmannibucau@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 <gu...@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 <
>> >> > >>>> rmannibucau@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
>> >> > >>>> > > <rm...@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
>> >> > >>>> > > >> <rm...@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-unsubscribe@commons.apache.org
>> >> > >>>> > > >> For additional commands, e-mail:
>> dev-help@commons.apache.org
>> >> > >>>> > > >>
>> >> > >>>> > > >>
>> >> > >>>> > >
>> >> > >>>> > >
>> >> > ---------------------------------------------------------------------
>> >> > >>>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> > >>>> > > For additional commands, e-mail: dev-help@commons.apache.org
>> >> > >>>> > >
>> >> > >>>> > >
>> >> > >>>> >
>> >> > >>>>
>> >> > >>>
>> >> > >>>
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> > For additional commands, e-mail: dev-help@commons.apache.org
>> >> >
>> >> >
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [proxy] and impl
Posted by James Carman <ja...@carmanconsulting.com>.
Holy cow! Can I borrow your notebook? ;).
On Sunday, August 4, 2013, Mark Struberg wrote:
> JFTR: in Apache OpenWebBeans we switched to ASM because Javassist caused
> too much mem leaks and hassles.
>
> But we do only use reflection when it's really needed. Means methods which
> are neither delegated nor intercepted will delegated via native java calls.
> The same happens for 'NormalScoped' proxies (a CDI specialty) which only
> use pure java code and no reflection.
>
> That said, a few figures: 10 million invocations on the proxies we
> generate using ASM (which do the getInstance() internally as well ->
> ThreadLocal, Map lookup, etc) take 30ms on my notebook.
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
> > From: Romain Manni-Bucau <rm...@gmail.com>
> > To: Commons Developers List <de...@commons.apache.org>
> > Cc:
> > Sent: Thursday, 1 August 2013, 17:15
> > Subject: Re: [proxy] and impl
> >
> > hehe, do you have figures?
> >
> > when JIT did its work reflection is almost free. You can update the asm
> > proxy factory to handle 3 implementations but it is not worth it IMO
> >
> > *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'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
> >> <rm...@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 <gu...@gmail.com>
> >> >
> >> >> That's my point; it doesn't.
> >> >>
> >> >>
> >> >> On Thu, Aug 1, 2013 at 9:49 AM, James Carman <
> >> james@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
> >> >> > <rm...@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/>
Re: [proxy] and impl
Posted by Mark Struberg <st...@yahoo.de>.
JFTR: in Apache OpenWebBeans we switched to ASM because Javassist caused too much mem leaks and hassles.
But we do only use reflection when it's really needed. Means methods which are neither delegated nor intercepted will delegated via native java calls.
The same happens for 'NormalScoped' proxies (a CDI specialty) which only use pure java code and no reflection.
That said, a few figures: 10 million invocations on the proxies we generate using ASM (which do the getInstance() internally as well -> ThreadLocal, Map lookup, etc) take 30ms on my notebook.
LieGrue,
strub
----- Original Message -----
> From: Romain Manni-Bucau <rm...@gmail.com>
> To: Commons Developers List <de...@commons.apache.org>
> Cc:
> Sent: Thursday, 1 August 2013, 17:15
> Subject: Re: [proxy] and impl
>
> hehe, do you have figures?
>
> when JIT did its work reflection is almost free. You can update the asm
> proxy factory to handle 3 implementations but it is not worth it IMO
>
> *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'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
>> <rm...@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 <gu...@gmail.com>
>> >
>> >> That's my point; it doesn't.
>> >>
>> >>
>> >> On Thu, Aug 1, 2013 at 9:49 AM, James Carman <
>> james@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
>> >> > <rm...@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 <gu...@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" <
>> rmannibucau@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
> <gu...@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 <
>> >> > >>>> rmannibucau@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
>> >> > >>>> > > <rm...@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
>> >> > >>>> > > >>
> <rm...@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-unsubscribe@commons.apache.org
>> >> > >>>> > > >> For additional commands,
> e-mail:
>> dev-help@commons.apache.org
>> >> > >>>> > > >>
>> >> > >>>> > > >>
>> >> > >>>> > >
>> >> > >>>> > >
>> >> >
> ---------------------------------------------------------------------
>> >> > >>>> > > To unsubscribe, e-mail:
> dev-unsubscribe@commons.apache.org
>> >> > >>>> > > For additional commands, e-mail:
> dev-help@commons.apache.org
>> >> > >>>> > >
>> >> > >>>> > >
>> >> > >>>> >
>> >> > >>>>
>> >> > >>>
>> >> > >>>
>> >> >
>> >> >
> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> > For additional commands, e-mail: dev-help@commons.apache.org
>> >> >
>> >> >
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [proxy] and impl
Posted by Romain Manni-Bucau <rm...@gmail.com>.
hehe, do you have figures?
when JIT did its work reflection is almost free. You can update the asm
proxy factory to handle 3 implementations but it is not worth it IMO
*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'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
> <rm...@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 <gu...@gmail.com>
> >
> >> That's my point; it doesn't.
> >>
> >>
> >> On Thu, Aug 1, 2013 at 9:49 AM, James Carman <
> james@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
> >> > <rm...@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 <gu...@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" <
> rmannibucau@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 <gu...@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 <
> >> > >>>> rmannibucau@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
> >> > >>>> > > <rm...@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
> >> > >>>> > > >> <rm...@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-unsubscribe@commons.apache.org
> >> > >>>> > > >> For additional commands, e-mail:
> dev-help@commons.apache.org
> >> > >>>> > > >>
> >> > >>>> > > >>
> >> > >>>> > >
> >> > >>>> > >
> >> > ---------------------------------------------------------------------
> >> > >>>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> > >>>> > > For additional commands, e-mail: dev-help@commons.apache.org
> >> > >>>> > >
> >> > >>>> > >
> >> > >>>> >
> >> > >>>>
> >> > >>>
> >> > >>>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> > For additional commands, e-mail: dev-help@commons.apache.org
> >> >
> >> >
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [proxy] and impl
Posted by Matt Benson <gu...@gmail.com>.
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
> <rm...@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 <gu...@gmail.com>
> >
> >> That's my point; it doesn't.
> >>
> >>
> >> On Thu, Aug 1, 2013 at 9:49 AM, James Carman <
> james@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
> >> > <rm...@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 <gu...@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" <
> rmannibucau@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 <gu...@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 <
> >> > >>>> rmannibucau@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
> >> > >>>> > > <rm...@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
> >> > >>>> > > >> <rm...@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-unsubscribe@commons.apache.org
> >> > >>>> > > >> For additional commands, e-mail:
> dev-help@commons.apache.org
> >> > >>>> > > >>
> >> > >>>> > > >>
> >> > >>>> > >
> >> > >>>> > >
> >> > ---------------------------------------------------------------------
> >> > >>>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> > >>>> > > For additional commands, e-mail: dev-help@commons.apache.org
> >> > >>>> > >
> >> > >>>> > >
> >> > >>>> >
> >> > >>>>
> >> > >>>
> >> > >>>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> > For additional commands, e-mail: dev-help@commons.apache.org
> >> >
> >> >
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [proxy] and impl
Posted by James Carman <ja...@carmanconsulting.com>.
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
<rm...@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 <gu...@gmail.com>
>
>> That's my point; it doesn't.
>>
>>
>> On Thu, Aug 1, 2013 at 9:49 AM, James Carman <james@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
>> > <rm...@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 <gu...@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" <rm...@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 <gu...@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 <
>> > >>>> rmannibucau@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
>> > >>>> > > <rm...@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
>> > >>>> > > >> <rm...@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-unsubscribe@commons.apache.org
>> > >>>> > > >> For additional commands, e-mail: dev-help@commons.apache.org
>> > >>>> > > >>
>> > >>>> > > >>
>> > >>>> > >
>> > >>>> > >
>> > ---------------------------------------------------------------------
>> > >>>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > >>>> > > For additional commands, e-mail: dev-help@commons.apache.org
>> > >>>> > >
>> > >>>> > >
>> > >>>> >
>> > >>>>
>> > >>>
>> > >>>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>> >
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [proxy] and impl
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <gu...@gmail.com>
> That's my point; it doesn't.
>
>
> On Thu, Aug 1, 2013 at 9:49 AM, James Carman <james@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
> > <rm...@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 <gu...@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" <rm...@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 <gu...@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 <
> > >>>> rmannibucau@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
> > >>>> > > <rm...@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
> > >>>> > > >> <rm...@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-unsubscribe@commons.apache.org
> > >>>> > > >> For additional commands, e-mail: dev-help@commons.apache.org
> > >>>> > > >>
> > >>>> > > >>
> > >>>> > >
> > >>>> > >
> > ---------------------------------------------------------------------
> > >>>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >>>> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >>>> > >
> > >>>> > >
> > >>>> >
> > >>>>
> > >>>
> > >>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
Re: [proxy] and impl
Posted by Matt Benson <gu...@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
> <rm...@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 <gu...@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" <rm...@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 <gu...@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 <
> >>>> rmannibucau@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
> >>>> > > <rm...@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
> >>>> > > >> <rm...@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-unsubscribe@commons.apache.org
> >>>> > > >> For additional commands, e-mail: dev-help@commons.apache.org
> >>>> > > >>
> >>>> > > >>
> >>>> > >
> >>>> > >
> ---------------------------------------------------------------------
> >>>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>> > > For additional commands, e-mail: dev-help@commons.apache.org
> >>>> > >
> >>>> > >
> >>>> >
> >>>>
> >>>
> >>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [proxy] and impl
Posted by James Carman <ja...@carmanconsulting.com>.
Does the ASM API require a java.lang.reflect.InvocationHandler?
On Thu, Aug 1, 2013 at 10:41 AM, Romain Manni-Bucau
<rm...@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 <gu...@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" <rm...@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 <gu...@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 <
>>>> rmannibucau@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
>>>> > > <rm...@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
>>>> > > >> <rm...@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-unsubscribe@commons.apache.org
>>>> > > >> For additional commands, e-mail: dev-help@commons.apache.org
>>>> > > >>
>>>> > > >>
>>>> > >
>>>> > > ---------------------------------------------------------------------
>>>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> > > For additional commands, e-mail: dev-help@commons.apache.org
>>>> > >
>>>> > >
>>>> >
>>>>
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [proxy] and impl
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <gu...@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" <rm...@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 <gu...@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 <
>>> rmannibucau@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
>>> > > <rm...@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
>>> > > >> <rm...@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-unsubscribe@commons.apache.org
>>> > > >> For additional commands, e-mail: dev-help@commons.apache.org
>>> > > >>
>>> > > >>
>>> > >
>>> > > ---------------------------------------------------------------------
>>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> > > For additional commands, e-mail: dev-help@commons.apache.org
>>> > >
>>> > >
>>> >
>>>
>>
>>
Re: [proxy] and impl
Posted by Matt Benson <gu...@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" <rm...@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 <gu...@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 <rmannibucau@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
>> > > <rm...@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
>> > > >> <rm...@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-unsubscribe@commons.apache.org
>> > > >> For additional commands, e-mail: dev-help@commons.apache.org
>> > > >>
>> > > >>
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > > For additional commands, e-mail: dev-help@commons.apache.org
>> > >
>> > >
>> >
>>
>
>
Re: [proxy] and impl
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <gu...@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 <rmannibucau@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
> > > <rm...@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
> > > >> <rm...@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-unsubscribe@commons.apache.org
> > > >> For additional commands, e-mail: dev-help@commons.apache.org
> > > >>
> > > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
>
Re: [proxy] and impl
Posted by Matt Benson <gu...@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 <rm...@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
> > <rm...@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
> > >> <rm...@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-unsubscribe@commons.apache.org
> > >> For additional commands, e-mail: dev-help@commons.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
Re: [proxy] and impl
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+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
> <rm...@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
> >> <rm...@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [proxy] and impl
Posted by 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
<rm...@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
>> <rm...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [proxy] and impl
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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
> <rm...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [proxy] and impl
Posted by James Carman <ja...@carmanconsulting.com>.
On Thu, Aug 1, 2013 at 2:44 AM, Romain Manni-Bucau
<rm...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [proxy] and impl
Posted by Romain Manni-Bucau <rm...@gmail.com>.
ok,
here it is: https://gist.github.com/rmannibucau/6128964
btw I have some question and notes about what i saw in proxy2:
1) i didn't fully get the goal of stub module, any pointers?
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.
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
*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/7/31 James Carman <ja...@carmanconsulting.com>
> I know. I mean can we get a patch against the 2.x branch.
>
>
> On Wed, Jul 31, 2013 at 3:44 PM, Matt Benson <gu...@gmail.com> wrote:
> > Since [proxy] is in proper, Romain probably doesn't (yet) have access to
> > commit this himself.
> >
> > Matt
> >
> >
> > On Wed, Jul 31, 2013 at 2:31 PM, James Carman <
> james@carmanconsulting.com>wrote:
> >
> >> Any chance you could hook that into our existing test suite? We have
> >> a base class for all ProxyFactory tests. Also, could you apply your
> >> fix to the 2.0 branch? We're not upgrading proxy-1.x to Java 6.
> >> That's happening in the 2.x release.
> >>
> >> On Wed, Jul 31, 2013 at 3:07 PM, Romain Manni-Bucau
> >> <rm...@gmail.com> wrote:
> >> > Hi
> >> >
> >> > here is the asm4-shaded impl:
> >> https://gist.github.com/rmannibucau/6125125
> >> >
> >> > *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/7/29 Romain Manni-Bucau <rm...@gmail.com>
> >> >
> >> >> hmm not sure i follow, here we don't shade asm (it is already done)
> and
> >> if
> >> >> all libs shade it we will have at least 5 shade of the same version
> in
> >> >> tomee for instance (same comment on the app side) so that's not a
> >> solution
> >> >> for each lib. [proxy] is small enough to not shade IMO. That said if
> >> your
> >> >> relocation trick works it would be enough to copy classes with
> >> relocation
> >> >> in 3-4 places.
> >> >>
> >> >> *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/7/29 Matt Benson <gu...@gmail.com>
> >> >>
> >> >>> Rather than duplicating code I thought we could code to asm4's
> released
> >> >>> jars, and provide the basic proxy-asm artifact. Then shade asm4 and
> >> >>> provide proxy-asm-shaded. Then optionally, we could create another
> >> shaded
> >> >>> jar that relocates to the same destination as xbean-shaded-asm4 but
> >> does
> >> >>> not actually shade the classes. I think maven-shade-plugin would do
> >> this
> >> >>> by specifying relocations without the artifactSet, though I haven't
> >> tried
> >> >>> it. Then we support:
> >> >>>
> >> >>> * asm4 is on classpath
> >> >>> * one well-known shading that the user may already have on the
> >> classpath
> >> >>> * dependencies shaded to a namespace specific to proxy-asm
> >> >>>
> >> >>> One of these options will work in every case. Even ASM's own FAQ
> >> >>> recommends the equivalent of shading per consuming library[1].
> >> >>>
> >> >>> Matt
> >> >>>
> >> >>> [1] http://asm.ow2.org/doc/faq.html#Q15
> >> >>>
> >> >>>
> >> >>> On Mon, Jul 29, 2013 at 9:59 AM, Romain Manni-Bucau <
> >> >>> rmannibucau@gmail.com> wrote:
> >> >>>
> >> >>>> You have the clean proxy code here (just rework the method
> generation
> >> >>>> which is a bit different):
> >> >>>>
> >>
> http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/util/proxy/LocalBeanProxyFactory.java
> >> >>>>
> >> >>>> the point is i already have cases where i want to use asm and asm
> >> >>>> shaded, we can multiply the impl number too but it would duplicate
> >> the code.
> >> >>>>
> >> >>>> About the perf a bench would say it, i didn't take time to do it.
> >> >>>>
> >> >>>> *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/7/29 Matt Benson <gu...@gmail.com>
> >> >>>>
> >> >>>>>
> >> >>>>> On Sun, Jul 28, 2013 at 12:16 PM, Romain Manni-Bucau <
> >> >>>>> rmannibucau@gmail.com> wrote:
> >> >>>>>
> >> >>>>>> answers inline
> >> >>>>>>
> >> >>>>>> *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/7/28 Matt Benson <gu...@gmail.com>
> >> >>>>>>
> >> >>>>>>> Interesting patch. I have some questions and comments:
> >> >>>>>>>
> >> >>>>>>> - You'd additionally need to make sure the impl class is
> non-final,
> >> >>>>>>> no?
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>> hmm, good question i didn't check but with asm we can subclass
> final
> >> >>>>>> classes, hehe
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> We can? How devious... well, then strike my question.
> >> >>>>>
> >> >>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> - note to others that asm4-shaded is used because asm didn't
> change
> >> >>>>>>> packages from v3. Good to see this in use; I hadn't kept track
> >> after
> >> >>>>>>> submitting that patch. ;-)
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>> i used asm4 since that's the more up to date and it supports
> java 7
> >> >>>>>> very well. The shade was used since provided in tomee and owb but
> >> real asm
> >> >>>>>> should be fine (see next point)
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> - Would you explain the purpose of the AsmFacade class? Much of
> the
> >> >>>>>>> "nuts and bolts" work of the patch seems quite different from
> what
> >> I
> >> >>>>>>> perceive as "typical asm client code."
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>> i first wrote it with asm imports but a common issue is: do i use
> >> asm?
> >> >>>>>> spring-asm-shade? xbean-asm-shade? so AsmFacade is an utility
> class
> >> to
> >> >>>>>> allow to use whatever impl is here (almost).
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>> While I find this to be interesting and quite clever, I feel like
> >> it's
> >> >>>>> maybe too much. For one point, have you tried searching the web
> for
> >> >>>>> meaningful examples of ASM code? It's not that easy IMO. I think
> >> it'd be
> >> >>>>> nicer for our ASM code to exemplify "normal" ASM as much as
> >> possible. I'd
> >> >>>>> say it'd be enough to write the basic impl against stock asm4.
> If we
> >> >>>>> wanted we could then provide one artifact that shades asm4, and
> >> another
> >> >>>>> that rewrites the compiled classes to depend on xbean-shaded-asm4,
> >> and
> >> >>>>> surely that would be enough for users to get by with. Then our
> code
> >> would
> >> >>>>> be more intelligible as well as useful from the perspective of
> >> helping
> >> >>>>> other devs learn from good examples.
> >> >>>>>
> >> >>>>> Back to the subject of cglib, do you expect this implementation
> >> should
> >> >>>>>>> significantly outperform it for any reason ( if so, which? ), or
> >> is the
> >> >>>>>>> main motivation that cglib is almost dead as you say?
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>> since cglib is dead we need something else and i expect the impl
> to
> >> be
> >> >>>>>> faster than javassist. Another nice side effect is no dep in a
> >> container
> >> >>>>>> providing asm.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>> I am taking this as still saying, yes, the ASM proxy
> implementation
> >> >>>>> might not be any faster than cglib. ;) Which is fine.
> >> >>>>>
> >> >>>>> Thanks!
> >> >>>>>
> >> >>>>> Matt
> >> >>>>>
> >> >>>>>
> >> >>>>>> Thanks and regards,
> >> >>>>>>> Matt
> >> >>>>>>> On Jul 28, 2013 10:58 AM, "Romain Manni-Bucau" <
> >> rmannibucau@gmail.com>
> >> >>>>>>> wrote:
> >> >>>>>>>
> >> >>>>>>>> Hi
> >> >>>>>>>>
> >> >>>>>>>> here is a patch implementing proxying using ASM:
> >> >>>>>>>> https://gist.github.com/rmannibucau/6099063
> >> >>>>>>>>
> >> >>>>>>>> having the handlers used by default in ProxyFactory protected
> >> would
> >> >>>>>>>> avoid to copy them in ASMProxyFactory.
> >> >>>>>>>>
> >> >>>>>>>> *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/7/28 Romain Manni-Bucau <rm...@gmail.com>
> >> >>>>>>>>
> >> >>>>>>>>> Cglib is "almost" dead if i'm right, javassist is alive but
> not
> >> >>>>>>>>> that stable and owb is faster ATM and at least would bring an
> >> Apache impl
> >> >>>>>>>>> adapted to [proxy].
> >> >>>>>>>>>
> >> >>>>>>>>> Note: the fact to be able to reuse InvocationHandler and not a
> >> new
> >> >>>>>>>>> API is great too
> >> >>>>>>>>> Le 27 juil. 2013 20:13, "Matt Benson" <gu...@gmail.com>
> a
> >> >>>>>>>>> écrit :
> >> >>>>>>>>>
> >> >>>>>>>>> AFAIK Mark Struberg's work on the OWB proxies could be
> >> instructive,
> >> >>>>>>>>>> and
> >> >>>>>>>>>> since I've just spent several weeks in ASM hell I might just
> be
> >> a
> >> >>>>>>>>>> bit of
> >> >>>>>>>>>> use there myself. The only thing is, isn't cglib built on
> ASM as
> >> >>>>>>>>>> well? The
> >> >>>>>>>>>> dynamic nature of the various proxy helpers means that we
> >> probably
> >> >>>>>>>>>> couldn't
> >> >>>>>>>>>> really improve on cglib, i.e. only if we could test
> invocation
> >> >>>>>>>>>> matching up
> >> >>>>>>>>>> front while creating the proxy class would we be faster.
> >> >>>>>>>>>>
> >> >>>>>>>>>> Matt
> >> >>>>>>>>>> On Jul 27, 2013 12:22 PM, "Romain Manni-Bucau" <
> >> >>>>>>>>>> rmannibucau@gmail.com>
> >> >>>>>>>>>> wrote:
> >> >>>>>>>>>>
> >> >>>>>>>>>> > Hehe, we benched in owb but lets wait the porting ;)
> >> >>>>>>>>>> > Le 27 juil. 2013 16:49, "James Carman" <
> >> >>>>>>>>>> james@carmanconsulting.com> a
> >> >>>>>>>>>> > écrit :
> >> >>>>>>>>>> >
> >> >>>>>>>>>> > > On Sat, Jul 27, 2013 at 10:34 AM, Romain Manni-Bucau
> >> >>>>>>>>>> > > <rm...@gmail.com> wrote:
> >> >>>>>>>>>> > > > Once ill have done the monitoring stuff ill try to
> work on
> >> >>>>>>>>>> it.
> >> >>>>>>>>>> > >
> >> >>>>>>>>>> > > What would be really cool is to have a "smackdown" once
> we
> >> get
> >> >>>>>>>>>> ASM
> >> >>>>>>>>>> > > into the mix to see which one performs the best and
> exactly
> >> >>>>>>>>>> how fast
> >> >>>>>>>>>> > > they are compared to one another.
> >> >>>>>>>>>> > >
> >> >>>>>>>>>> > >
> >> >>>>>>>>>>
> >> ---------------------------------------------------------------------
> >> >>>>>>>>>> > > To unsubscribe, e-mail:
> dev-unsubscribe@commons.apache.org
> >> >>>>>>>>>> > > For additional commands, e-mail:
> >> dev-help@commons.apache.org
> >> >>>>>>>>>> > >
> >> >>>>>>>>>> > >
> >> >>>>>>>>>> >
> >> >>>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [proxy] and impl
Posted by James Carman <ja...@carmanconsulting.com>.
I know. I mean can we get a patch against the 2.x branch.
On Wed, Jul 31, 2013 at 3:44 PM, Matt Benson <gu...@gmail.com> wrote:
> Since [proxy] is in proper, Romain probably doesn't (yet) have access to
> commit this himself.
>
> Matt
>
>
> On Wed, Jul 31, 2013 at 2:31 PM, James Carman <ja...@carmanconsulting.com>wrote:
>
>> Any chance you could hook that into our existing test suite? We have
>> a base class for all ProxyFactory tests. Also, could you apply your
>> fix to the 2.0 branch? We're not upgrading proxy-1.x to Java 6.
>> That's happening in the 2.x release.
>>
>> On Wed, Jul 31, 2013 at 3:07 PM, Romain Manni-Bucau
>> <rm...@gmail.com> wrote:
>> > Hi
>> >
>> > here is the asm4-shaded impl:
>> https://gist.github.com/rmannibucau/6125125
>> >
>> > *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/7/29 Romain Manni-Bucau <rm...@gmail.com>
>> >
>> >> hmm not sure i follow, here we don't shade asm (it is already done) and
>> if
>> >> all libs shade it we will have at least 5 shade of the same version in
>> >> tomee for instance (same comment on the app side) so that's not a
>> solution
>> >> for each lib. [proxy] is small enough to not shade IMO. That said if
>> your
>> >> relocation trick works it would be enough to copy classes with
>> relocation
>> >> in 3-4 places.
>> >>
>> >> *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/7/29 Matt Benson <gu...@gmail.com>
>> >>
>> >>> Rather than duplicating code I thought we could code to asm4's released
>> >>> jars, and provide the basic proxy-asm artifact. Then shade asm4 and
>> >>> provide proxy-asm-shaded. Then optionally, we could create another
>> shaded
>> >>> jar that relocates to the same destination as xbean-shaded-asm4 but
>> does
>> >>> not actually shade the classes. I think maven-shade-plugin would do
>> this
>> >>> by specifying relocations without the artifactSet, though I haven't
>> tried
>> >>> it. Then we support:
>> >>>
>> >>> * asm4 is on classpath
>> >>> * one well-known shading that the user may already have on the
>> classpath
>> >>> * dependencies shaded to a namespace specific to proxy-asm
>> >>>
>> >>> One of these options will work in every case. Even ASM's own FAQ
>> >>> recommends the equivalent of shading per consuming library[1].
>> >>>
>> >>> Matt
>> >>>
>> >>> [1] http://asm.ow2.org/doc/faq.html#Q15
>> >>>
>> >>>
>> >>> On Mon, Jul 29, 2013 at 9:59 AM, Romain Manni-Bucau <
>> >>> rmannibucau@gmail.com> wrote:
>> >>>
>> >>>> You have the clean proxy code here (just rework the method generation
>> >>>> which is a bit different):
>> >>>>
>> http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/util/proxy/LocalBeanProxyFactory.java
>> >>>>
>> >>>> the point is i already have cases where i want to use asm and asm
>> >>>> shaded, we can multiply the impl number too but it would duplicate
>> the code.
>> >>>>
>> >>>> About the perf a bench would say it, i didn't take time to do it.
>> >>>>
>> >>>> *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/7/29 Matt Benson <gu...@gmail.com>
>> >>>>
>> >>>>>
>> >>>>> On Sun, Jul 28, 2013 at 12:16 PM, Romain Manni-Bucau <
>> >>>>> rmannibucau@gmail.com> wrote:
>> >>>>>
>> >>>>>> answers inline
>> >>>>>>
>> >>>>>> *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/7/28 Matt Benson <gu...@gmail.com>
>> >>>>>>
>> >>>>>>> Interesting patch. I have some questions and comments:
>> >>>>>>>
>> >>>>>>> - You'd additionally need to make sure the impl class is non-final,
>> >>>>>>> no?
>> >>>>>>>
>> >>>>>>
>> >>>>>> hmm, good question i didn't check but with asm we can subclass final
>> >>>>>> classes, hehe
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>> We can? How devious... well, then strike my question.
>> >>>>>
>> >>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> - note to others that asm4-shaded is used because asm didn't change
>> >>>>>>> packages from v3. Good to see this in use; I hadn't kept track
>> after
>> >>>>>>> submitting that patch. ;-)
>> >>>>>>>
>> >>>>>>
>> >>>>>> i used asm4 since that's the more up to date and it supports java 7
>> >>>>>> very well. The shade was used since provided in tomee and owb but
>> real asm
>> >>>>>> should be fine (see next point)
>> >>>>>>
>> >>>>>>
>> >>>>>>> - Would you explain the purpose of the AsmFacade class? Much of the
>> >>>>>>> "nuts and bolts" work of the patch seems quite different from what
>> I
>> >>>>>>> perceive as "typical asm client code."
>> >>>>>>>
>> >>>>>>
>> >>>>>> i first wrote it with asm imports but a common issue is: do i use
>> asm?
>> >>>>>> spring-asm-shade? xbean-asm-shade? so AsmFacade is an utility class
>> to
>> >>>>>> allow to use whatever impl is here (almost).
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>> While I find this to be interesting and quite clever, I feel like
>> it's
>> >>>>> maybe too much. For one point, have you tried searching the web for
>> >>>>> meaningful examples of ASM code? It's not that easy IMO. I think
>> it'd be
>> >>>>> nicer for our ASM code to exemplify "normal" ASM as much as
>> possible. I'd
>> >>>>> say it'd be enough to write the basic impl against stock asm4. If we
>> >>>>> wanted we could then provide one artifact that shades asm4, and
>> another
>> >>>>> that rewrites the compiled classes to depend on xbean-shaded-asm4,
>> and
>> >>>>> surely that would be enough for users to get by with. Then our code
>> would
>> >>>>> be more intelligible as well as useful from the perspective of
>> helping
>> >>>>> other devs learn from good examples.
>> >>>>>
>> >>>>> Back to the subject of cglib, do you expect this implementation
>> should
>> >>>>>>> significantly outperform it for any reason ( if so, which? ), or
>> is the
>> >>>>>>> main motivation that cglib is almost dead as you say?
>> >>>>>>>
>> >>>>>>
>> >>>>>> since cglib is dead we need something else and i expect the impl to
>> be
>> >>>>>> faster than javassist. Another nice side effect is no dep in a
>> container
>> >>>>>> providing asm.
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>> I am taking this as still saying, yes, the ASM proxy implementation
>> >>>>> might not be any faster than cglib. ;) Which is fine.
>> >>>>>
>> >>>>> Thanks!
>> >>>>>
>> >>>>> Matt
>> >>>>>
>> >>>>>
>> >>>>>> Thanks and regards,
>> >>>>>>> Matt
>> >>>>>>> On Jul 28, 2013 10:58 AM, "Romain Manni-Bucau" <
>> rmannibucau@gmail.com>
>> >>>>>>> wrote:
>> >>>>>>>
>> >>>>>>>> Hi
>> >>>>>>>>
>> >>>>>>>> here is a patch implementing proxying using ASM:
>> >>>>>>>> https://gist.github.com/rmannibucau/6099063
>> >>>>>>>>
>> >>>>>>>> having the handlers used by default in ProxyFactory protected
>> would
>> >>>>>>>> avoid to copy them in ASMProxyFactory.
>> >>>>>>>>
>> >>>>>>>> *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/7/28 Romain Manni-Bucau <rm...@gmail.com>
>> >>>>>>>>
>> >>>>>>>>> Cglib is "almost" dead if i'm right, javassist is alive but not
>> >>>>>>>>> that stable and owb is faster ATM and at least would bring an
>> Apache impl
>> >>>>>>>>> adapted to [proxy].
>> >>>>>>>>>
>> >>>>>>>>> Note: the fact to be able to reuse InvocationHandler and not a
>> new
>> >>>>>>>>> API is great too
>> >>>>>>>>> Le 27 juil. 2013 20:13, "Matt Benson" <gu...@gmail.com> a
>> >>>>>>>>> écrit :
>> >>>>>>>>>
>> >>>>>>>>> AFAIK Mark Struberg's work on the OWB proxies could be
>> instructive,
>> >>>>>>>>>> and
>> >>>>>>>>>> since I've just spent several weeks in ASM hell I might just be
>> a
>> >>>>>>>>>> bit of
>> >>>>>>>>>> use there myself. The only thing is, isn't cglib built on ASM as
>> >>>>>>>>>> well? The
>> >>>>>>>>>> dynamic nature of the various proxy helpers means that we
>> probably
>> >>>>>>>>>> couldn't
>> >>>>>>>>>> really improve on cglib, i.e. only if we could test invocation
>> >>>>>>>>>> matching up
>> >>>>>>>>>> front while creating the proxy class would we be faster.
>> >>>>>>>>>>
>> >>>>>>>>>> Matt
>> >>>>>>>>>> On Jul 27, 2013 12:22 PM, "Romain Manni-Bucau" <
>> >>>>>>>>>> rmannibucau@gmail.com>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> > Hehe, we benched in owb but lets wait the porting ;)
>> >>>>>>>>>> > Le 27 juil. 2013 16:49, "James Carman" <
>> >>>>>>>>>> james@carmanconsulting.com> a
>> >>>>>>>>>> > écrit :
>> >>>>>>>>>> >
>> >>>>>>>>>> > > On Sat, Jul 27, 2013 at 10:34 AM, Romain Manni-Bucau
>> >>>>>>>>>> > > <rm...@gmail.com> wrote:
>> >>>>>>>>>> > > > Once ill have done the monitoring stuff ill try to work on
>> >>>>>>>>>> it.
>> >>>>>>>>>> > >
>> >>>>>>>>>> > > What would be really cool is to have a "smackdown" once we
>> get
>> >>>>>>>>>> ASM
>> >>>>>>>>>> > > into the mix to see which one performs the best and exactly
>> >>>>>>>>>> how fast
>> >>>>>>>>>> > > they are compared to one another.
>> >>>>>>>>>> > >
>> >>>>>>>>>> > >
>> >>>>>>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>>>>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>>>>>>>>> > > For additional commands, e-mail:
>> dev-help@commons.apache.org
>> >>>>>>>>>> > >
>> >>>>>>>>>> > >
>> >>>>>>>>>> >
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [proxy] and impl
Posted by Matt Benson <gu...@gmail.com>.
Since [proxy] is in proper, Romain probably doesn't (yet) have access to
commit this himself.
Matt
On Wed, Jul 31, 2013 at 2:31 PM, James Carman <ja...@carmanconsulting.com>wrote:
> Any chance you could hook that into our existing test suite? We have
> a base class for all ProxyFactory tests. Also, could you apply your
> fix to the 2.0 branch? We're not upgrading proxy-1.x to Java 6.
> That's happening in the 2.x release.
>
> On Wed, Jul 31, 2013 at 3:07 PM, Romain Manni-Bucau
> <rm...@gmail.com> wrote:
> > Hi
> >
> > here is the asm4-shaded impl:
> https://gist.github.com/rmannibucau/6125125
> >
> > *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/7/29 Romain Manni-Bucau <rm...@gmail.com>
> >
> >> hmm not sure i follow, here we don't shade asm (it is already done) and
> if
> >> all libs shade it we will have at least 5 shade of the same version in
> >> tomee for instance (same comment on the app side) so that's not a
> solution
> >> for each lib. [proxy] is small enough to not shade IMO. That said if
> your
> >> relocation trick works it would be enough to copy classes with
> relocation
> >> in 3-4 places.
> >>
> >> *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/7/29 Matt Benson <gu...@gmail.com>
> >>
> >>> Rather than duplicating code I thought we could code to asm4's released
> >>> jars, and provide the basic proxy-asm artifact. Then shade asm4 and
> >>> provide proxy-asm-shaded. Then optionally, we could create another
> shaded
> >>> jar that relocates to the same destination as xbean-shaded-asm4 but
> does
> >>> not actually shade the classes. I think maven-shade-plugin would do
> this
> >>> by specifying relocations without the artifactSet, though I haven't
> tried
> >>> it. Then we support:
> >>>
> >>> * asm4 is on classpath
> >>> * one well-known shading that the user may already have on the
> classpath
> >>> * dependencies shaded to a namespace specific to proxy-asm
> >>>
> >>> One of these options will work in every case. Even ASM's own FAQ
> >>> recommends the equivalent of shading per consuming library[1].
> >>>
> >>> Matt
> >>>
> >>> [1] http://asm.ow2.org/doc/faq.html#Q15
> >>>
> >>>
> >>> On Mon, Jul 29, 2013 at 9:59 AM, Romain Manni-Bucau <
> >>> rmannibucau@gmail.com> wrote:
> >>>
> >>>> You have the clean proxy code here (just rework the method generation
> >>>> which is a bit different):
> >>>>
> http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/util/proxy/LocalBeanProxyFactory.java
> >>>>
> >>>> the point is i already have cases where i want to use asm and asm
> >>>> shaded, we can multiply the impl number too but it would duplicate
> the code.
> >>>>
> >>>> About the perf a bench would say it, i didn't take time to do it.
> >>>>
> >>>> *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/7/29 Matt Benson <gu...@gmail.com>
> >>>>
> >>>>>
> >>>>> On Sun, Jul 28, 2013 at 12:16 PM, Romain Manni-Bucau <
> >>>>> rmannibucau@gmail.com> wrote:
> >>>>>
> >>>>>> answers inline
> >>>>>>
> >>>>>> *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/7/28 Matt Benson <gu...@gmail.com>
> >>>>>>
> >>>>>>> Interesting patch. I have some questions and comments:
> >>>>>>>
> >>>>>>> - You'd additionally need to make sure the impl class is non-final,
> >>>>>>> no?
> >>>>>>>
> >>>>>>
> >>>>>> hmm, good question i didn't check but with asm we can subclass final
> >>>>>> classes, hehe
> >>>>>>
> >>>>>
> >>>>>
> >>>>> We can? How devious... well, then strike my question.
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>> - note to others that asm4-shaded is used because asm didn't change
> >>>>>>> packages from v3. Good to see this in use; I hadn't kept track
> after
> >>>>>>> submitting that patch. ;-)
> >>>>>>>
> >>>>>>
> >>>>>> i used asm4 since that's the more up to date and it supports java 7
> >>>>>> very well. The shade was used since provided in tomee and owb but
> real asm
> >>>>>> should be fine (see next point)
> >>>>>>
> >>>>>>
> >>>>>>> - Would you explain the purpose of the AsmFacade class? Much of the
> >>>>>>> "nuts and bolts" work of the patch seems quite different from what
> I
> >>>>>>> perceive as "typical asm client code."
> >>>>>>>
> >>>>>>
> >>>>>> i first wrote it with asm imports but a common issue is: do i use
> asm?
> >>>>>> spring-asm-shade? xbean-asm-shade? so AsmFacade is an utility class
> to
> >>>>>> allow to use whatever impl is here (almost).
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> While I find this to be interesting and quite clever, I feel like
> it's
> >>>>> maybe too much. For one point, have you tried searching the web for
> >>>>> meaningful examples of ASM code? It's not that easy IMO. I think
> it'd be
> >>>>> nicer for our ASM code to exemplify "normal" ASM as much as
> possible. I'd
> >>>>> say it'd be enough to write the basic impl against stock asm4. If we
> >>>>> wanted we could then provide one artifact that shades asm4, and
> another
> >>>>> that rewrites the compiled classes to depend on xbean-shaded-asm4,
> and
> >>>>> surely that would be enough for users to get by with. Then our code
> would
> >>>>> be more intelligible as well as useful from the perspective of
> helping
> >>>>> other devs learn from good examples.
> >>>>>
> >>>>> Back to the subject of cglib, do you expect this implementation
> should
> >>>>>>> significantly outperform it for any reason ( if so, which? ), or
> is the
> >>>>>>> main motivation that cglib is almost dead as you say?
> >>>>>>>
> >>>>>>
> >>>>>> since cglib is dead we need something else and i expect the impl to
> be
> >>>>>> faster than javassist. Another nice side effect is no dep in a
> container
> >>>>>> providing asm.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> I am taking this as still saying, yes, the ASM proxy implementation
> >>>>> might not be any faster than cglib. ;) Which is fine.
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> Matt
> >>>>>
> >>>>>
> >>>>>> Thanks and regards,
> >>>>>>> Matt
> >>>>>>> On Jul 28, 2013 10:58 AM, "Romain Manni-Bucau" <
> rmannibucau@gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hi
> >>>>>>>>
> >>>>>>>> here is a patch implementing proxying using ASM:
> >>>>>>>> https://gist.github.com/rmannibucau/6099063
> >>>>>>>>
> >>>>>>>> having the handlers used by default in ProxyFactory protected
> would
> >>>>>>>> avoid to copy them in ASMProxyFactory.
> >>>>>>>>
> >>>>>>>> *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/7/28 Romain Manni-Bucau <rm...@gmail.com>
> >>>>>>>>
> >>>>>>>>> Cglib is "almost" dead if i'm right, javassist is alive but not
> >>>>>>>>> that stable and owb is faster ATM and at least would bring an
> Apache impl
> >>>>>>>>> adapted to [proxy].
> >>>>>>>>>
> >>>>>>>>> Note: the fact to be able to reuse InvocationHandler and not a
> new
> >>>>>>>>> API is great too
> >>>>>>>>> Le 27 juil. 2013 20:13, "Matt Benson" <gu...@gmail.com> a
> >>>>>>>>> écrit :
> >>>>>>>>>
> >>>>>>>>> AFAIK Mark Struberg's work on the OWB proxies could be
> instructive,
> >>>>>>>>>> and
> >>>>>>>>>> since I've just spent several weeks in ASM hell I might just be
> a
> >>>>>>>>>> bit of
> >>>>>>>>>> use there myself. The only thing is, isn't cglib built on ASM as
> >>>>>>>>>> well? The
> >>>>>>>>>> dynamic nature of the various proxy helpers means that we
> probably
> >>>>>>>>>> couldn't
> >>>>>>>>>> really improve on cglib, i.e. only if we could test invocation
> >>>>>>>>>> matching up
> >>>>>>>>>> front while creating the proxy class would we be faster.
> >>>>>>>>>>
> >>>>>>>>>> Matt
> >>>>>>>>>> On Jul 27, 2013 12:22 PM, "Romain Manni-Bucau" <
> >>>>>>>>>> rmannibucau@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> > Hehe, we benched in owb but lets wait the porting ;)
> >>>>>>>>>> > Le 27 juil. 2013 16:49, "James Carman" <
> >>>>>>>>>> james@carmanconsulting.com> a
> >>>>>>>>>> > écrit :
> >>>>>>>>>> >
> >>>>>>>>>> > > On Sat, Jul 27, 2013 at 10:34 AM, Romain Manni-Bucau
> >>>>>>>>>> > > <rm...@gmail.com> wrote:
> >>>>>>>>>> > > > Once ill have done the monitoring stuff ill try to work on
> >>>>>>>>>> it.
> >>>>>>>>>> > >
> >>>>>>>>>> > > What would be really cool is to have a "smackdown" once we
> get
> >>>>>>>>>> ASM
> >>>>>>>>>> > > into the mix to see which one performs the best and exactly
> >>>>>>>>>> how fast
> >>>>>>>>>> > > they are compared to one another.
> >>>>>>>>>> > >
> >>>>>>>>>> > >
> >>>>>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>>>>>>> > > For additional commands, e-mail:
> dev-help@commons.apache.org
> >>>>>>>>>> > >
> >>>>>>>>>> > >
> >>>>>>>>>> >
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [proxy] and impl
Posted by James Carman <ja...@carmanconsulting.com>.
Any chance you could hook that into our existing test suite? We have
a base class for all ProxyFactory tests. Also, could you apply your
fix to the 2.0 branch? We're not upgrading proxy-1.x to Java 6.
That's happening in the 2.x release.
On Wed, Jul 31, 2013 at 3:07 PM, Romain Manni-Bucau
<rm...@gmail.com> wrote:
> Hi
>
> here is the asm4-shaded impl: https://gist.github.com/rmannibucau/6125125
>
> *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/7/29 Romain Manni-Bucau <rm...@gmail.com>
>
>> hmm not sure i follow, here we don't shade asm (it is already done) and if
>> all libs shade it we will have at least 5 shade of the same version in
>> tomee for instance (same comment on the app side) so that's not a solution
>> for each lib. [proxy] is small enough to not shade IMO. That said if your
>> relocation trick works it would be enough to copy classes with relocation
>> in 3-4 places.
>>
>> *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/7/29 Matt Benson <gu...@gmail.com>
>>
>>> Rather than duplicating code I thought we could code to asm4's released
>>> jars, and provide the basic proxy-asm artifact. Then shade asm4 and
>>> provide proxy-asm-shaded. Then optionally, we could create another shaded
>>> jar that relocates to the same destination as xbean-shaded-asm4 but does
>>> not actually shade the classes. I think maven-shade-plugin would do this
>>> by specifying relocations without the artifactSet, though I haven't tried
>>> it. Then we support:
>>>
>>> * asm4 is on classpath
>>> * one well-known shading that the user may already have on the classpath
>>> * dependencies shaded to a namespace specific to proxy-asm
>>>
>>> One of these options will work in every case. Even ASM's own FAQ
>>> recommends the equivalent of shading per consuming library[1].
>>>
>>> Matt
>>>
>>> [1] http://asm.ow2.org/doc/faq.html#Q15
>>>
>>>
>>> On Mon, Jul 29, 2013 at 9:59 AM, Romain Manni-Bucau <
>>> rmannibucau@gmail.com> wrote:
>>>
>>>> You have the clean proxy code here (just rework the method generation
>>>> which is a bit different):
>>>> http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/util/proxy/LocalBeanProxyFactory.java
>>>>
>>>> the point is i already have cases where i want to use asm and asm
>>>> shaded, we can multiply the impl number too but it would duplicate the code.
>>>>
>>>> About the perf a bench would say it, i didn't take time to do it.
>>>>
>>>> *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/7/29 Matt Benson <gu...@gmail.com>
>>>>
>>>>>
>>>>> On Sun, Jul 28, 2013 at 12:16 PM, Romain Manni-Bucau <
>>>>> rmannibucau@gmail.com> wrote:
>>>>>
>>>>>> answers inline
>>>>>>
>>>>>> *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/7/28 Matt Benson <gu...@gmail.com>
>>>>>>
>>>>>>> Interesting patch. I have some questions and comments:
>>>>>>>
>>>>>>> - You'd additionally need to make sure the impl class is non-final,
>>>>>>> no?
>>>>>>>
>>>>>>
>>>>>> hmm, good question i didn't check but with asm we can subclass final
>>>>>> classes, hehe
>>>>>>
>>>>>
>>>>>
>>>>> We can? How devious... well, then strike my question.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>> - note to others that asm4-shaded is used because asm didn't change
>>>>>>> packages from v3. Good to see this in use; I hadn't kept track after
>>>>>>> submitting that patch. ;-)
>>>>>>>
>>>>>>
>>>>>> i used asm4 since that's the more up to date and it supports java 7
>>>>>> very well. The shade was used since provided in tomee and owb but real asm
>>>>>> should be fine (see next point)
>>>>>>
>>>>>>
>>>>>>> - Would you explain the purpose of the AsmFacade class? Much of the
>>>>>>> "nuts and bolts" work of the patch seems quite different from what I
>>>>>>> perceive as "typical asm client code."
>>>>>>>
>>>>>>
>>>>>> i first wrote it with asm imports but a common issue is: do i use asm?
>>>>>> spring-asm-shade? xbean-asm-shade? so AsmFacade is an utility class to
>>>>>> allow to use whatever impl is here (almost).
>>>>>>
>>>>>>
>>>>>
>>>>> While I find this to be interesting and quite clever, I feel like it's
>>>>> maybe too much. For one point, have you tried searching the web for
>>>>> meaningful examples of ASM code? It's not that easy IMO. I think it'd be
>>>>> nicer for our ASM code to exemplify "normal" ASM as much as possible. I'd
>>>>> say it'd be enough to write the basic impl against stock asm4. If we
>>>>> wanted we could then provide one artifact that shades asm4, and another
>>>>> that rewrites the compiled classes to depend on xbean-shaded-asm4, and
>>>>> surely that would be enough for users to get by with. Then our code would
>>>>> be more intelligible as well as useful from the perspective of helping
>>>>> other devs learn from good examples.
>>>>>
>>>>> Back to the subject of cglib, do you expect this implementation should
>>>>>>> significantly outperform it for any reason ( if so, which? ), or is the
>>>>>>> main motivation that cglib is almost dead as you say?
>>>>>>>
>>>>>>
>>>>>> since cglib is dead we need something else and i expect the impl to be
>>>>>> faster than javassist. Another nice side effect is no dep in a container
>>>>>> providing asm.
>>>>>>
>>>>>>
>>>>>
>>>>> I am taking this as still saying, yes, the ASM proxy implementation
>>>>> might not be any faster than cglib. ;) Which is fine.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Matt
>>>>>
>>>>>
>>>>>> Thanks and regards,
>>>>>>> Matt
>>>>>>> On Jul 28, 2013 10:58 AM, "Romain Manni-Bucau" <rm...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> here is a patch implementing proxying using ASM:
>>>>>>>> https://gist.github.com/rmannibucau/6099063
>>>>>>>>
>>>>>>>> having the handlers used by default in ProxyFactory protected would
>>>>>>>> avoid to copy them in ASMProxyFactory.
>>>>>>>>
>>>>>>>> *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/7/28 Romain Manni-Bucau <rm...@gmail.com>
>>>>>>>>
>>>>>>>>> Cglib is "almost" dead if i'm right, javassist is alive but not
>>>>>>>>> that stable and owb is faster ATM and at least would bring an Apache impl
>>>>>>>>> adapted to [proxy].
>>>>>>>>>
>>>>>>>>> Note: the fact to be able to reuse InvocationHandler and not a new
>>>>>>>>> API is great too
>>>>>>>>> Le 27 juil. 2013 20:13, "Matt Benson" <gu...@gmail.com> a
>>>>>>>>> écrit :
>>>>>>>>>
>>>>>>>>> AFAIK Mark Struberg's work on the OWB proxies could be instructive,
>>>>>>>>>> and
>>>>>>>>>> since I've just spent several weeks in ASM hell I might just be a
>>>>>>>>>> bit of
>>>>>>>>>> use there myself. The only thing is, isn't cglib built on ASM as
>>>>>>>>>> well? The
>>>>>>>>>> dynamic nature of the various proxy helpers means that we probably
>>>>>>>>>> couldn't
>>>>>>>>>> really improve on cglib, i.e. only if we could test invocation
>>>>>>>>>> matching up
>>>>>>>>>> front while creating the proxy class would we be faster.
>>>>>>>>>>
>>>>>>>>>> Matt
>>>>>>>>>> On Jul 27, 2013 12:22 PM, "Romain Manni-Bucau" <
>>>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> > Hehe, we benched in owb but lets wait the porting ;)
>>>>>>>>>> > Le 27 juil. 2013 16:49, "James Carman" <
>>>>>>>>>> james@carmanconsulting.com> a
>>>>>>>>>> > écrit :
>>>>>>>>>> >
>>>>>>>>>> > > On Sat, Jul 27, 2013 at 10:34 AM, Romain Manni-Bucau
>>>>>>>>>> > > <rm...@gmail.com> wrote:
>>>>>>>>>> > > > Once ill have done the monitoring stuff ill try to work on
>>>>>>>>>> it.
>>>>>>>>>> > >
>>>>>>>>>> > > What would be really cool is to have a "smackdown" once we get
>>>>>>>>>> ASM
>>>>>>>>>> > > into the mix to see which one performs the best and exactly
>>>>>>>>>> how fast
>>>>>>>>>> > > they are compared to one another.
>>>>>>>>>> > >
>>>>>>>>>> > >
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>> > > For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>> > >
>>>>>>>>>> > >
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [proxy] and impl
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
here is the asm4-shaded impl: https://gist.github.com/rmannibucau/6125125
*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/7/29 Romain Manni-Bucau <rm...@gmail.com>
> hmm not sure i follow, here we don't shade asm (it is already done) and if
> all libs shade it we will have at least 5 shade of the same version in
> tomee for instance (same comment on the app side) so that's not a solution
> for each lib. [proxy] is small enough to not shade IMO. That said if your
> relocation trick works it would be enough to copy classes with relocation
> in 3-4 places.
>
> *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/7/29 Matt Benson <gu...@gmail.com>
>
>> Rather than duplicating code I thought we could code to asm4's released
>> jars, and provide the basic proxy-asm artifact. Then shade asm4 and
>> provide proxy-asm-shaded. Then optionally, we could create another shaded
>> jar that relocates to the same destination as xbean-shaded-asm4 but does
>> not actually shade the classes. I think maven-shade-plugin would do this
>> by specifying relocations without the artifactSet, though I haven't tried
>> it. Then we support:
>>
>> * asm4 is on classpath
>> * one well-known shading that the user may already have on the classpath
>> * dependencies shaded to a namespace specific to proxy-asm
>>
>> One of these options will work in every case. Even ASM's own FAQ
>> recommends the equivalent of shading per consuming library[1].
>>
>> Matt
>>
>> [1] http://asm.ow2.org/doc/faq.html#Q15
>>
>>
>> On Mon, Jul 29, 2013 at 9:59 AM, Romain Manni-Bucau <
>> rmannibucau@gmail.com> wrote:
>>
>>> You have the clean proxy code here (just rework the method generation
>>> which is a bit different):
>>> http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/util/proxy/LocalBeanProxyFactory.java
>>>
>>> the point is i already have cases where i want to use asm and asm
>>> shaded, we can multiply the impl number too but it would duplicate the code.
>>>
>>> About the perf a bench would say it, i didn't take time to do it.
>>>
>>> *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/7/29 Matt Benson <gu...@gmail.com>
>>>
>>>>
>>>> On Sun, Jul 28, 2013 at 12:16 PM, Romain Manni-Bucau <
>>>> rmannibucau@gmail.com> wrote:
>>>>
>>>>> answers inline
>>>>>
>>>>> *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/7/28 Matt Benson <gu...@gmail.com>
>>>>>
>>>>>> Interesting patch. I have some questions and comments:
>>>>>>
>>>>>> - You'd additionally need to make sure the impl class is non-final,
>>>>>> no?
>>>>>>
>>>>>
>>>>> hmm, good question i didn't check but with asm we can subclass final
>>>>> classes, hehe
>>>>>
>>>>
>>>>
>>>> We can? How devious... well, then strike my question.
>>>>
>>>>
>>>>>
>>>>>
>>>>>> - note to others that asm4-shaded is used because asm didn't change
>>>>>> packages from v3. Good to see this in use; I hadn't kept track after
>>>>>> submitting that patch. ;-)
>>>>>>
>>>>>
>>>>> i used asm4 since that's the more up to date and it supports java 7
>>>>> very well. The shade was used since provided in tomee and owb but real asm
>>>>> should be fine (see next point)
>>>>>
>>>>>
>>>>>> - Would you explain the purpose of the AsmFacade class? Much of the
>>>>>> "nuts and bolts" work of the patch seems quite different from what I
>>>>>> perceive as "typical asm client code."
>>>>>>
>>>>>
>>>>> i first wrote it with asm imports but a common issue is: do i use asm?
>>>>> spring-asm-shade? xbean-asm-shade? so AsmFacade is an utility class to
>>>>> allow to use whatever impl is here (almost).
>>>>>
>>>>>
>>>>
>>>> While I find this to be interesting and quite clever, I feel like it's
>>>> maybe too much. For one point, have you tried searching the web for
>>>> meaningful examples of ASM code? It's not that easy IMO. I think it'd be
>>>> nicer for our ASM code to exemplify "normal" ASM as much as possible. I'd
>>>> say it'd be enough to write the basic impl against stock asm4. If we
>>>> wanted we could then provide one artifact that shades asm4, and another
>>>> that rewrites the compiled classes to depend on xbean-shaded-asm4, and
>>>> surely that would be enough for users to get by with. Then our code would
>>>> be more intelligible as well as useful from the perspective of helping
>>>> other devs learn from good examples.
>>>>
>>>> Back to the subject of cglib, do you expect this implementation should
>>>>>> significantly outperform it for any reason ( if so, which? ), or is the
>>>>>> main motivation that cglib is almost dead as you say?
>>>>>>
>>>>>
>>>>> since cglib is dead we need something else and i expect the impl to be
>>>>> faster than javassist. Another nice side effect is no dep in a container
>>>>> providing asm.
>>>>>
>>>>>
>>>>
>>>> I am taking this as still saying, yes, the ASM proxy implementation
>>>> might not be any faster than cglib. ;) Which is fine.
>>>>
>>>> Thanks!
>>>>
>>>> Matt
>>>>
>>>>
>>>>> Thanks and regards,
>>>>>> Matt
>>>>>> On Jul 28, 2013 10:58 AM, "Romain Manni-Bucau" <rm...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> here is a patch implementing proxying using ASM:
>>>>>>> https://gist.github.com/rmannibucau/6099063
>>>>>>>
>>>>>>> having the handlers used by default in ProxyFactory protected would
>>>>>>> avoid to copy them in ASMProxyFactory.
>>>>>>>
>>>>>>> *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/7/28 Romain Manni-Bucau <rm...@gmail.com>
>>>>>>>
>>>>>>>> Cglib is "almost" dead if i'm right, javassist is alive but not
>>>>>>>> that stable and owb is faster ATM and at least would bring an Apache impl
>>>>>>>> adapted to [proxy].
>>>>>>>>
>>>>>>>> Note: the fact to be able to reuse InvocationHandler and not a new
>>>>>>>> API is great too
>>>>>>>> Le 27 juil. 2013 20:13, "Matt Benson" <gu...@gmail.com> a
>>>>>>>> écrit :
>>>>>>>>
>>>>>>>> AFAIK Mark Struberg's work on the OWB proxies could be instructive,
>>>>>>>>> and
>>>>>>>>> since I've just spent several weeks in ASM hell I might just be a
>>>>>>>>> bit of
>>>>>>>>> use there myself. The only thing is, isn't cglib built on ASM as
>>>>>>>>> well? The
>>>>>>>>> dynamic nature of the various proxy helpers means that we probably
>>>>>>>>> couldn't
>>>>>>>>> really improve on cglib, i.e. only if we could test invocation
>>>>>>>>> matching up
>>>>>>>>> front while creating the proxy class would we be faster.
>>>>>>>>>
>>>>>>>>> Matt
>>>>>>>>> On Jul 27, 2013 12:22 PM, "Romain Manni-Bucau" <
>>>>>>>>> rmannibucau@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> > Hehe, we benched in owb but lets wait the porting ;)
>>>>>>>>> > Le 27 juil. 2013 16:49, "James Carman" <
>>>>>>>>> james@carmanconsulting.com> a
>>>>>>>>> > écrit :
>>>>>>>>> >
>>>>>>>>> > > On Sat, Jul 27, 2013 at 10:34 AM, Romain Manni-Bucau
>>>>>>>>> > > <rm...@gmail.com> wrote:
>>>>>>>>> > > > Once ill have done the monitoring stuff ill try to work on
>>>>>>>>> it.
>>>>>>>>> > >
>>>>>>>>> > > What would be really cool is to have a "smackdown" once we get
>>>>>>>>> ASM
>>>>>>>>> > > into the mix to see which one performs the best and exactly
>>>>>>>>> how fast
>>>>>>>>> > > they are compared to one another.
>>>>>>>>> > >
>>>>>>>>> > >
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>> > > For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>> > >
>>>>>>>>> > >
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [proxy] and impl
Posted by Romain Manni-Bucau <rm...@gmail.com>.
hmm not sure i follow, here we don't shade asm (it is already done) and if
all libs shade it we will have at least 5 shade of the same version in
tomee for instance (same comment on the app side) so that's not a solution
for each lib. [proxy] is small enough to not shade IMO. That said if your
relocation trick works it would be enough to copy classes with relocation
in 3-4 places.
*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/7/29 Matt Benson <gu...@gmail.com>
> Rather than duplicating code I thought we could code to asm4's released
> jars, and provide the basic proxy-asm artifact. Then shade asm4 and
> provide proxy-asm-shaded. Then optionally, we could create another shaded
> jar that relocates to the same destination as xbean-shaded-asm4 but does
> not actually shade the classes. I think maven-shade-plugin would do this
> by specifying relocations without the artifactSet, though I haven't tried
> it. Then we support:
>
> * asm4 is on classpath
> * one well-known shading that the user may already have on the classpath
> * dependencies shaded to a namespace specific to proxy-asm
>
> One of these options will work in every case. Even ASM's own FAQ
> recommends the equivalent of shading per consuming library[1].
>
> Matt
>
> [1] http://asm.ow2.org/doc/faq.html#Q15
>
>
> On Mon, Jul 29, 2013 at 9:59 AM, Romain Manni-Bucau <rmannibucau@gmail.com
> > wrote:
>
>> You have the clean proxy code here (just rework the method generation
>> which is a bit different):
>> http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/util/proxy/LocalBeanProxyFactory.java
>>
>> the point is i already have cases where i want to use asm and asm shaded,
>> we can multiply the impl number too but it would duplicate the code.
>>
>> About the perf a bench would say it, i didn't take time to do it.
>>
>> *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/7/29 Matt Benson <gu...@gmail.com>
>>
>>>
>>> On Sun, Jul 28, 2013 at 12:16 PM, Romain Manni-Bucau <
>>> rmannibucau@gmail.com> wrote:
>>>
>>>> answers inline
>>>>
>>>> *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/7/28 Matt Benson <gu...@gmail.com>
>>>>
>>>>> Interesting patch. I have some questions and comments:
>>>>>
>>>>> - You'd additionally need to make sure the impl class is non-final,
>>>>> no?
>>>>>
>>>>
>>>> hmm, good question i didn't check but with asm we can subclass final
>>>> classes, hehe
>>>>
>>>
>>>
>>> We can? How devious... well, then strike my question.
>>>
>>>
>>>>
>>>>
>>>>> - note to others that asm4-shaded is used because asm didn't change
>>>>> packages from v3. Good to see this in use; I hadn't kept track after
>>>>> submitting that patch. ;-)
>>>>>
>>>>
>>>> i used asm4 since that's the more up to date and it supports java 7
>>>> very well. The shade was used since provided in tomee and owb but real asm
>>>> should be fine (see next point)
>>>>
>>>>
>>>>> - Would you explain the purpose of the AsmFacade class? Much of the
>>>>> "nuts and bolts" work of the patch seems quite different from what I
>>>>> perceive as "typical asm client code."
>>>>>
>>>>
>>>> i first wrote it with asm imports but a common issue is: do i use asm?
>>>> spring-asm-shade? xbean-asm-shade? so AsmFacade is an utility class to
>>>> allow to use whatever impl is here (almost).
>>>>
>>>>
>>>
>>> While I find this to be interesting and quite clever, I feel like it's
>>> maybe too much. For one point, have you tried searching the web for
>>> meaningful examples of ASM code? It's not that easy IMO. I think it'd be
>>> nicer for our ASM code to exemplify "normal" ASM as much as possible. I'd
>>> say it'd be enough to write the basic impl against stock asm4. If we
>>> wanted we could then provide one artifact that shades asm4, and another
>>> that rewrites the compiled classes to depend on xbean-shaded-asm4, and
>>> surely that would be enough for users to get by with. Then our code would
>>> be more intelligible as well as useful from the perspective of helping
>>> other devs learn from good examples.
>>>
>>> Back to the subject of cglib, do you expect this implementation should
>>>>> significantly outperform it for any reason ( if so, which? ), or is the
>>>>> main motivation that cglib is almost dead as you say?
>>>>>
>>>>
>>>> since cglib is dead we need something else and i expect the impl to be
>>>> faster than javassist. Another nice side effect is no dep in a container
>>>> providing asm.
>>>>
>>>>
>>>
>>> I am taking this as still saying, yes, the ASM proxy implementation
>>> might not be any faster than cglib. ;) Which is fine.
>>>
>>> Thanks!
>>>
>>> Matt
>>>
>>>
>>>> Thanks and regards,
>>>>> Matt
>>>>> On Jul 28, 2013 10:58 AM, "Romain Manni-Bucau" <rm...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> here is a patch implementing proxying using ASM:
>>>>>> https://gist.github.com/rmannibucau/6099063
>>>>>>
>>>>>> having the handlers used by default in ProxyFactory protected would
>>>>>> avoid to copy them in ASMProxyFactory.
>>>>>>
>>>>>> *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/7/28 Romain Manni-Bucau <rm...@gmail.com>
>>>>>>
>>>>>>> Cglib is "almost" dead if i'm right, javassist is alive but not that
>>>>>>> stable and owb is faster ATM and at least would bring an Apache impl
>>>>>>> adapted to [proxy].
>>>>>>>
>>>>>>> Note: the fact to be able to reuse InvocationHandler and not a new
>>>>>>> API is great too
>>>>>>> Le 27 juil. 2013 20:13, "Matt Benson" <gu...@gmail.com> a
>>>>>>> écrit :
>>>>>>>
>>>>>>> AFAIK Mark Struberg's work on the OWB proxies could be instructive,
>>>>>>>> and
>>>>>>>> since I've just spent several weeks in ASM hell I might just be a
>>>>>>>> bit of
>>>>>>>> use there myself. The only thing is, isn't cglib built on ASM as
>>>>>>>> well? The
>>>>>>>> dynamic nature of the various proxy helpers means that we probably
>>>>>>>> couldn't
>>>>>>>> really improve on cglib, i.e. only if we could test invocation
>>>>>>>> matching up
>>>>>>>> front while creating the proxy class would we be faster.
>>>>>>>>
>>>>>>>> Matt
>>>>>>>> On Jul 27, 2013 12:22 PM, "Romain Manni-Bucau" <
>>>>>>>> rmannibucau@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> > Hehe, we benched in owb but lets wait the porting ;)
>>>>>>>> > Le 27 juil. 2013 16:49, "James Carman" <
>>>>>>>> james@carmanconsulting.com> a
>>>>>>>> > écrit :
>>>>>>>> >
>>>>>>>> > > On Sat, Jul 27, 2013 at 10:34 AM, Romain Manni-Bucau
>>>>>>>> > > <rm...@gmail.com> wrote:
>>>>>>>> > > > Once ill have done the monitoring stuff ill try to work on it.
>>>>>>>> > >
>>>>>>>> > > What would be really cool is to have a "smackdown" once we get
>>>>>>>> ASM
>>>>>>>> > > into the mix to see which one performs the best and exactly how
>>>>>>>> fast
>>>>>>>> > > they are compared to one another.
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> > > For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> >
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>
Re: [proxy] and impl
Posted by Matt Benson <gu...@gmail.com>.
Rather than duplicating code I thought we could code to asm4's released
jars, and provide the basic proxy-asm artifact. Then shade asm4 and
provide proxy-asm-shaded. Then optionally, we could create another shaded
jar that relocates to the same destination as xbean-shaded-asm4 but does
not actually shade the classes. I think maven-shade-plugin would do this
by specifying relocations without the artifactSet, though I haven't tried
it. Then we support:
* asm4 is on classpath
* one well-known shading that the user may already have on the classpath
* dependencies shaded to a namespace specific to proxy-asm
One of these options will work in every case. Even ASM's own FAQ
recommends the equivalent of shading per consuming library[1].
Matt
[1] http://asm.ow2.org/doc/faq.html#Q15
On Mon, Jul 29, 2013 at 9:59 AM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> You have the clean proxy code here (just rework the method generation
> which is a bit different):
> http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/util/proxy/LocalBeanProxyFactory.java
>
> the point is i already have cases where i want to use asm and asm shaded,
> we can multiply the impl number too but it would duplicate the code.
>
> About the perf a bench would say it, i didn't take time to do it.
>
> *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/7/29 Matt Benson <gu...@gmail.com>
>
>>
>> On Sun, Jul 28, 2013 at 12:16 PM, Romain Manni-Bucau <
>> rmannibucau@gmail.com> wrote:
>>
>>> answers inline
>>>
>>> *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/7/28 Matt Benson <gu...@gmail.com>
>>>
>>>> Interesting patch. I have some questions and comments:
>>>>
>>>> - You'd additionally need to make sure the impl class is non-final, no?
>>>>
>>>
>>> hmm, good question i didn't check but with asm we can subclass final
>>> classes, hehe
>>>
>>
>>
>> We can? How devious... well, then strike my question.
>>
>>
>>>
>>>
>>>> - note to others that asm4-shaded is used because asm didn't change
>>>> packages from v3. Good to see this in use; I hadn't kept track after
>>>> submitting that patch. ;-)
>>>>
>>>
>>> i used asm4 since that's the more up to date and it supports java 7 very
>>> well. The shade was used since provided in tomee and owb but real asm
>>> should be fine (see next point)
>>>
>>>
>>>> - Would you explain the purpose of the AsmFacade class? Much of the
>>>> "nuts and bolts" work of the patch seems quite different from what I
>>>> perceive as "typical asm client code."
>>>>
>>>
>>> i first wrote it with asm imports but a common issue is: do i use asm?
>>> spring-asm-shade? xbean-asm-shade? so AsmFacade is an utility class to
>>> allow to use whatever impl is here (almost).
>>>
>>>
>>
>> While I find this to be interesting and quite clever, I feel like it's
>> maybe too much. For one point, have you tried searching the web for
>> meaningful examples of ASM code? It's not that easy IMO. I think it'd be
>> nicer for our ASM code to exemplify "normal" ASM as much as possible. I'd
>> say it'd be enough to write the basic impl against stock asm4. If we
>> wanted we could then provide one artifact that shades asm4, and another
>> that rewrites the compiled classes to depend on xbean-shaded-asm4, and
>> surely that would be enough for users to get by with. Then our code would
>> be more intelligible as well as useful from the perspective of helping
>> other devs learn from good examples.
>>
>> Back to the subject of cglib, do you expect this implementation should
>>>> significantly outperform it for any reason ( if so, which? ), or is the
>>>> main motivation that cglib is almost dead as you say?
>>>>
>>>
>>> since cglib is dead we need something else and i expect the impl to be
>>> faster than javassist. Another nice side effect is no dep in a container
>>> providing asm.
>>>
>>>
>>
>> I am taking this as still saying, yes, the ASM proxy implementation might
>> not be any faster than cglib. ;) Which is fine.
>>
>> Thanks!
>>
>> Matt
>>
>>
>>> Thanks and regards,
>>>> Matt
>>>> On Jul 28, 2013 10:58 AM, "Romain Manni-Bucau" <rm...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> here is a patch implementing proxying using ASM:
>>>>> https://gist.github.com/rmannibucau/6099063
>>>>>
>>>>> having the handlers used by default in ProxyFactory protected would
>>>>> avoid to copy them in ASMProxyFactory.
>>>>>
>>>>> *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/7/28 Romain Manni-Bucau <rm...@gmail.com>
>>>>>
>>>>>> Cglib is "almost" dead if i'm right, javassist is alive but not that
>>>>>> stable and owb is faster ATM and at least would bring an Apache impl
>>>>>> adapted to [proxy].
>>>>>>
>>>>>> Note: the fact to be able to reuse InvocationHandler and not a new
>>>>>> API is great too
>>>>>> Le 27 juil. 2013 20:13, "Matt Benson" <gu...@gmail.com> a
>>>>>> écrit :
>>>>>>
>>>>>> AFAIK Mark Struberg's work on the OWB proxies could be instructive,
>>>>>>> and
>>>>>>> since I've just spent several weeks in ASM hell I might just be a
>>>>>>> bit of
>>>>>>> use there myself. The only thing is, isn't cglib built on ASM as
>>>>>>> well? The
>>>>>>> dynamic nature of the various proxy helpers means that we probably
>>>>>>> couldn't
>>>>>>> really improve on cglib, i.e. only if we could test invocation
>>>>>>> matching up
>>>>>>> front while creating the proxy class would we be faster.
>>>>>>>
>>>>>>> Matt
>>>>>>> On Jul 27, 2013 12:22 PM, "Romain Manni-Bucau" <
>>>>>>> rmannibucau@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> > Hehe, we benched in owb but lets wait the porting ;)
>>>>>>> > Le 27 juil. 2013 16:49, "James Carman" <ja...@carmanconsulting.com>
>>>>>>> a
>>>>>>> > écrit :
>>>>>>> >
>>>>>>> > > On Sat, Jul 27, 2013 at 10:34 AM, Romain Manni-Bucau
>>>>>>> > > <rm...@gmail.com> wrote:
>>>>>>> > > > Once ill have done the monitoring stuff ill try to work on it.
>>>>>>> > >
>>>>>>> > > What would be really cool is to have a "smackdown" once we get
>>>>>>> ASM
>>>>>>> > > into the mix to see which one performs the best and exactly how
>>>>>>> fast
>>>>>>> > > they are compared to one another.
>>>>>>> > >
>>>>>>> > >
>>>>>>> ---------------------------------------------------------------------
>>>>>>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> > > For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>> > >
>>>>>>> > >
>>>>>>> >
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>
Re: [proxy] and impl
Posted by Romain Manni-Bucau <rm...@gmail.com>.
You have the clean proxy code here (just rework the method generation which
is a bit different):
http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/util/proxy/LocalBeanProxyFactory.java
the point is i already have cases where i want to use asm and asm shaded,
we can multiply the impl number too but it would duplicate the code.
About the perf a bench would say it, i didn't take time to do it.
*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/7/29 Matt Benson <gu...@gmail.com>
>
> On Sun, Jul 28, 2013 at 12:16 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com> wrote:
>
>> answers inline
>>
>> *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/7/28 Matt Benson <gu...@gmail.com>
>>
>>> Interesting patch. I have some questions and comments:
>>>
>>> - You'd additionally need to make sure the impl class is non-final, no?
>>>
>>
>> hmm, good question i didn't check but with asm we can subclass final
>> classes, hehe
>>
>
>
> We can? How devious... well, then strike my question.
>
>
>>
>>
>>> - note to others that asm4-shaded is used because asm didn't change
>>> packages from v3. Good to see this in use; I hadn't kept track after
>>> submitting that patch. ;-)
>>>
>>
>> i used asm4 since that's the more up to date and it supports java 7 very
>> well. The shade was used since provided in tomee and owb but real asm
>> should be fine (see next point)
>>
>>
>>> - Would you explain the purpose of the AsmFacade class? Much of the
>>> "nuts and bolts" work of the patch seems quite different from what I
>>> perceive as "typical asm client code."
>>>
>>
>> i first wrote it with asm imports but a common issue is: do i use asm?
>> spring-asm-shade? xbean-asm-shade? so AsmFacade is an utility class to
>> allow to use whatever impl is here (almost).
>>
>>
>
> While I find this to be interesting and quite clever, I feel like it's
> maybe too much. For one point, have you tried searching the web for
> meaningful examples of ASM code? It's not that easy IMO. I think it'd be
> nicer for our ASM code to exemplify "normal" ASM as much as possible. I'd
> say it'd be enough to write the basic impl against stock asm4. If we
> wanted we could then provide one artifact that shades asm4, and another
> that rewrites the compiled classes to depend on xbean-shaded-asm4, and
> surely that would be enough for users to get by with. Then our code would
> be more intelligible as well as useful from the perspective of helping
> other devs learn from good examples.
>
> Back to the subject of cglib, do you expect this implementation should
>>> significantly outperform it for any reason ( if so, which? ), or is the
>>> main motivation that cglib is almost dead as you say?
>>>
>>
>> since cglib is dead we need something else and i expect the impl to be
>> faster than javassist. Another nice side effect is no dep in a container
>> providing asm.
>>
>>
>
> I am taking this as still saying, yes, the ASM proxy implementation might
> not be any faster than cglib. ;) Which is fine.
>
> Thanks!
>
> Matt
>
>
>> Thanks and regards,
>>> Matt
>>> On Jul 28, 2013 10:58 AM, "Romain Manni-Bucau" <rm...@gmail.com>
>>> wrote:
>>>
>>>> Hi
>>>>
>>>> here is a patch implementing proxying using ASM:
>>>> https://gist.github.com/rmannibucau/6099063
>>>>
>>>> having the handlers used by default in ProxyFactory protected would
>>>> avoid to copy them in ASMProxyFactory.
>>>>
>>>> *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/7/28 Romain Manni-Bucau <rm...@gmail.com>
>>>>
>>>>> Cglib is "almost" dead if i'm right, javassist is alive but not that
>>>>> stable and owb is faster ATM and at least would bring an Apache impl
>>>>> adapted to [proxy].
>>>>>
>>>>> Note: the fact to be able to reuse InvocationHandler and not a new API
>>>>> is great too
>>>>> Le 27 juil. 2013 20:13, "Matt Benson" <gu...@gmail.com> a écrit :
>>>>>
>>>>> AFAIK Mark Struberg's work on the OWB proxies could be instructive, and
>>>>>> since I've just spent several weeks in ASM hell I might just be a bit
>>>>>> of
>>>>>> use there myself. The only thing is, isn't cglib built on ASM as
>>>>>> well? The
>>>>>> dynamic nature of the various proxy helpers means that we probably
>>>>>> couldn't
>>>>>> really improve on cglib, i.e. only if we could test invocation
>>>>>> matching up
>>>>>> front while creating the proxy class would we be faster.
>>>>>>
>>>>>> Matt
>>>>>> On Jul 27, 2013 12:22 PM, "Romain Manni-Bucau" <rmannibucau@gmail.com
>>>>>> >
>>>>>> wrote:
>>>>>>
>>>>>> > Hehe, we benched in owb but lets wait the porting ;)
>>>>>> > Le 27 juil. 2013 16:49, "James Carman" <ja...@carmanconsulting.com>
>>>>>> a
>>>>>> > écrit :
>>>>>> >
>>>>>> > > On Sat, Jul 27, 2013 at 10:34 AM, Romain Manni-Bucau
>>>>>> > > <rm...@gmail.com> wrote:
>>>>>> > > > Once ill have done the monitoring stuff ill try to work on it.
>>>>>> > >
>>>>>> > > What would be really cool is to have a "smackdown" once we get ASM
>>>>>> > > into the mix to see which one performs the best and exactly how
>>>>>> fast
>>>>>> > > they are compared to one another.
>>>>>> > >
>>>>>> > >
>>>>>> ---------------------------------------------------------------------
>>>>>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> > > For additional commands, e-mail: dev-help@commons.apache.org
>>>>>> > >
>>>>>> > >
>>>>>> >
>>>>>>
>>>>>
>>>>
>>
>
Re: [proxy] and impl
Posted by Matt Benson <gu...@gmail.com>.
On Sun, Jul 28, 2013 at 12:16 PM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> answers inline
>
> *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/7/28 Matt Benson <gu...@gmail.com>
>
>> Interesting patch. I have some questions and comments:
>>
>> - You'd additionally need to make sure the impl class is non-final, no?
>>
>
> hmm, good question i didn't check but with asm we can subclass final
> classes, hehe
>
We can? How devious... well, then strike my question.
>
>
>> - note to others that asm4-shaded is used because asm didn't change
>> packages from v3. Good to see this in use; I hadn't kept track after
>> submitting that patch. ;-)
>>
>
> i used asm4 since that's the more up to date and it supports java 7 very
> well. The shade was used since provided in tomee and owb but real asm
> should be fine (see next point)
>
>
>> - Would you explain the purpose of the AsmFacade class? Much of the "nuts
>> and bolts" work of the patch seems quite different from what I perceive as
>> "typical asm client code."
>>
>
> i first wrote it with asm imports but a common issue is: do i use asm?
> spring-asm-shade? xbean-asm-shade? so AsmFacade is an utility class to
> allow to use whatever impl is here (almost).
>
>
While I find this to be interesting and quite clever, I feel like it's
maybe too much. For one point, have you tried searching the web for
meaningful examples of ASM code? It's not that easy IMO. I think it'd be
nicer for our ASM code to exemplify "normal" ASM as much as possible. I'd
say it'd be enough to write the basic impl against stock asm4. If we
wanted we could then provide one artifact that shades asm4, and another
that rewrites the compiled classes to depend on xbean-shaded-asm4, and
surely that would be enough for users to get by with. Then our code would
be more intelligible as well as useful from the perspective of helping
other devs learn from good examples.
Back to the subject of cglib, do you expect this implementation should
>> significantly outperform it for any reason ( if so, which? ), or is the
>> main motivation that cglib is almost dead as you say?
>>
>
> since cglib is dead we need something else and i expect the impl to be
> faster than javassist. Another nice side effect is no dep in a container
> providing asm.
>
>
I am taking this as still saying, yes, the ASM proxy implementation might
not be any faster than cglib. ;) Which is fine.
Thanks!
Matt
> Thanks and regards,
>> Matt
>> On Jul 28, 2013 10:58 AM, "Romain Manni-Bucau" <rm...@gmail.com>
>> wrote:
>>
>>> Hi
>>>
>>> here is a patch implementing proxying using ASM:
>>> https://gist.github.com/rmannibucau/6099063
>>>
>>> having the handlers used by default in ProxyFactory protected would
>>> avoid to copy them in ASMProxyFactory.
>>>
>>> *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/7/28 Romain Manni-Bucau <rm...@gmail.com>
>>>
>>>> Cglib is "almost" dead if i'm right, javassist is alive but not that
>>>> stable and owb is faster ATM and at least would bring an Apache impl
>>>> adapted to [proxy].
>>>>
>>>> Note: the fact to be able to reuse InvocationHandler and not a new API
>>>> is great too
>>>> Le 27 juil. 2013 20:13, "Matt Benson" <gu...@gmail.com> a écrit :
>>>>
>>>> AFAIK Mark Struberg's work on the OWB proxies could be instructive, and
>>>>> since I've just spent several weeks in ASM hell I might just be a bit
>>>>> of
>>>>> use there myself. The only thing is, isn't cglib built on ASM as well?
>>>>> The
>>>>> dynamic nature of the various proxy helpers means that we probably
>>>>> couldn't
>>>>> really improve on cglib, i.e. only if we could test invocation
>>>>> matching up
>>>>> front while creating the proxy class would we be faster.
>>>>>
>>>>> Matt
>>>>> On Jul 27, 2013 12:22 PM, "Romain Manni-Bucau" <rm...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> > Hehe, we benched in owb but lets wait the porting ;)
>>>>> > Le 27 juil. 2013 16:49, "James Carman" <ja...@carmanconsulting.com>
>>>>> a
>>>>> > écrit :
>>>>> >
>>>>> > > On Sat, Jul 27, 2013 at 10:34 AM, Romain Manni-Bucau
>>>>> > > <rm...@gmail.com> wrote:
>>>>> > > > Once ill have done the monitoring stuff ill try to work on it.
>>>>> > >
>>>>> > > What would be really cool is to have a "smackdown" once we get ASM
>>>>> > > into the mix to see which one performs the best and exactly how
>>>>> fast
>>>>> > > they are compared to one another.
>>>>> > >
>>>>> > >
>>>>> ---------------------------------------------------------------------
>>>>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> > > For additional commands, e-mail: dev-help@commons.apache.org
>>>>> > >
>>>>> > >
>>>>> >
>>>>>
>>>>
>>>
>
Re: [proxy] and impl
Posted by Romain Manni-Bucau <rm...@gmail.com>.
answers inline
*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/7/28 Matt Benson <gu...@gmail.com>
> Interesting patch. I have some questions and comments:
>
> - You'd additionally need to make sure the impl class is non-final, no?
>
hmm, good question i didn't check but with asm we can subclass final
classes, hehe
> - note to others that asm4-shaded is used because asm didn't change
> packages from v3. Good to see this in use; I hadn't kept track after
> submitting that patch. ;-)
>
i used asm4 since that's the more up to date and it supports java 7 very
well. The shade was used since provided in tomee and owb but real asm
should be fine (see next point)
> - Would you explain the purpose of the AsmFacade class? Much of the "nuts
> and bolts" work of the patch seems quite different from what I perceive as
> "typical asm client code."
>
i first wrote it with asm imports but a common issue is: do i use asm?
spring-asm-shade? xbean-asm-shade? so AsmFacade is an utility class to
allow to use whatever impl is here (almost).
> Back to the subject of cglib, do you expect this implementation should
> significantly outperform it for any reason ( if so, which? ), or is the
> main motivation that cglib is almost dead as you say?
>
since cglib is dead we need something else and i expect the impl to be
faster than javassist. Another nice side effect is no dep in a container
providing asm.
> Thanks and regards,
> Matt
> On Jul 28, 2013 10:58 AM, "Romain Manni-Bucau" <rm...@gmail.com>
> wrote:
>
>> Hi
>>
>> here is a patch implementing proxying using ASM:
>> https://gist.github.com/rmannibucau/6099063
>>
>> having the handlers used by default in ProxyFactory protected would avoid
>> to copy them in ASMProxyFactory.
>>
>> *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/7/28 Romain Manni-Bucau <rm...@gmail.com>
>>
>>> Cglib is "almost" dead if i'm right, javassist is alive but not that
>>> stable and owb is faster ATM and at least would bring an Apache impl
>>> adapted to [proxy].
>>>
>>> Note: the fact to be able to reuse InvocationHandler and not a new API
>>> is great too
>>> Le 27 juil. 2013 20:13, "Matt Benson" <gu...@gmail.com> a écrit :
>>>
>>> AFAIK Mark Struberg's work on the OWB proxies could be instructive, and
>>>> since I've just spent several weeks in ASM hell I might just be a bit of
>>>> use there myself. The only thing is, isn't cglib built on ASM as well?
>>>> The
>>>> dynamic nature of the various proxy helpers means that we probably
>>>> couldn't
>>>> really improve on cglib, i.e. only if we could test invocation matching
>>>> up
>>>> front while creating the proxy class would we be faster.
>>>>
>>>> Matt
>>>> On Jul 27, 2013 12:22 PM, "Romain Manni-Bucau" <rm...@gmail.com>
>>>> wrote:
>>>>
>>>> > Hehe, we benched in owb but lets wait the porting ;)
>>>> > Le 27 juil. 2013 16:49, "James Carman" <ja...@carmanconsulting.com> a
>>>> > écrit :
>>>> >
>>>> > > On Sat, Jul 27, 2013 at 10:34 AM, Romain Manni-Bucau
>>>> > > <rm...@gmail.com> wrote:
>>>> > > > Once ill have done the monitoring stuff ill try to work on it.
>>>> > >
>>>> > > What would be really cool is to have a "smackdown" once we get ASM
>>>> > > into the mix to see which one performs the best and exactly how fast
>>>> > > they are compared to one another.
>>>> > >
>>>> > >
>>>> ---------------------------------------------------------------------
>>>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> > > For additional commands, e-mail: dev-help@commons.apache.org
>>>> > >
>>>> > >
>>>> >
>>>>
>>>
>>
Re: [proxy] and impl
Posted by Matt Benson <gu...@gmail.com>.
Interesting patch. I have some questions and comments:
- You'd additionally need to make sure the impl class is non-final, no?
- note to others that asm4-shaded is used because asm didn't change
packages from v3. Good to see this in use; I hadn't kept track after
submitting that patch. ;-)
- Would you explain the purpose of the AsmFacade class? Much of the "nuts
and bolts" work of the patch seems quite different from what I perceive as
"typical asm client code."
Back to the subject of cglib, do you expect this implementation should
significantly outperform it for any reason ( if so, which? ), or is the
main motivation that cglib is almost dead as you say?
Thanks and regards,
Matt
On Jul 28, 2013 10:58 AM, "Romain Manni-Bucau" <rm...@gmail.com>
wrote:
> Hi
>
> here is a patch implementing proxying using ASM:
> https://gist.github.com/rmannibucau/6099063
>
> having the handlers used by default in ProxyFactory protected would avoid
> to copy them in ASMProxyFactory.
>
> *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/7/28 Romain Manni-Bucau <rm...@gmail.com>
>
>> Cglib is "almost" dead if i'm right, javassist is alive but not that
>> stable and owb is faster ATM and at least would bring an Apache impl
>> adapted to [proxy].
>>
>> Note: the fact to be able to reuse InvocationHandler and not a new API is
>> great too
>> Le 27 juil. 2013 20:13, "Matt Benson" <gu...@gmail.com> a écrit :
>>
>> AFAIK Mark Struberg's work on the OWB proxies could be instructive, and
>>> since I've just spent several weeks in ASM hell I might just be a bit of
>>> use there myself. The only thing is, isn't cglib built on ASM as well?
>>> The
>>> dynamic nature of the various proxy helpers means that we probably
>>> couldn't
>>> really improve on cglib, i.e. only if we could test invocation matching
>>> up
>>> front while creating the proxy class would we be faster.
>>>
>>> Matt
>>> On Jul 27, 2013 12:22 PM, "Romain Manni-Bucau" <rm...@gmail.com>
>>> wrote:
>>>
>>> > Hehe, we benched in owb but lets wait the porting ;)
>>> > Le 27 juil. 2013 16:49, "James Carman" <ja...@carmanconsulting.com> a
>>> > écrit :
>>> >
>>> > > On Sat, Jul 27, 2013 at 10:34 AM, Romain Manni-Bucau
>>> > > <rm...@gmail.com> wrote:
>>> > > > Once ill have done the monitoring stuff ill try to work on it.
>>> > >
>>> > > What would be really cool is to have a "smackdown" once we get ASM
>>> > > into the mix to see which one performs the best and exactly how fast
>>> > > they are compared to one another.
>>> > >
>>> > > ---------------------------------------------------------------------
>>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> > > For additional commands, e-mail: dev-help@commons.apache.org
>>> > >
>>> > >
>>> >
>>>
>>
>
Re: [proxy] and impl
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
here is a patch implementing proxying using ASM:
https://gist.github.com/rmannibucau/6099063
having the handlers used by default in ProxyFactory protected would avoid
to copy them in ASMProxyFactory.
*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/7/28 Romain Manni-Bucau <rm...@gmail.com>
> Cglib is "almost" dead if i'm right, javassist is alive but not that
> stable and owb is faster ATM and at least would bring an Apache impl
> adapted to [proxy].
>
> Note: the fact to be able to reuse InvocationHandler and not a new API is
> great too
> Le 27 juil. 2013 20:13, "Matt Benson" <gu...@gmail.com> a écrit :
>
> AFAIK Mark Struberg's work on the OWB proxies could be instructive, and
>> since I've just spent several weeks in ASM hell I might just be a bit of
>> use there myself. The only thing is, isn't cglib built on ASM as well? The
>> dynamic nature of the various proxy helpers means that we probably
>> couldn't
>> really improve on cglib, i.e. only if we could test invocation matching up
>> front while creating the proxy class would we be faster.
>>
>> Matt
>> On Jul 27, 2013 12:22 PM, "Romain Manni-Bucau" <rm...@gmail.com>
>> wrote:
>>
>> > Hehe, we benched in owb but lets wait the porting ;)
>> > Le 27 juil. 2013 16:49, "James Carman" <ja...@carmanconsulting.com> a
>> > écrit :
>> >
>> > > On Sat, Jul 27, 2013 at 10:34 AM, Romain Manni-Bucau
>> > > <rm...@gmail.com> wrote:
>> > > > Once ill have done the monitoring stuff ill try to work on it.
>> > >
>> > > What would be really cool is to have a "smackdown" once we get ASM
>> > > into the mix to see which one performs the best and exactly how fast
>> > > they are compared to one another.
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > > For additional commands, e-mail: dev-help@commons.apache.org
>> > >
>> > >
>> >
>>
>
Re: [proxy] and impl
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Cglib is "almost" dead if i'm right, javassist is alive but not that stable
and owb is faster ATM and at least would bring an Apache impl adapted to
[proxy].
Note: the fact to be able to reuse InvocationHandler and not a new API is
great too
Le 27 juil. 2013 20:13, "Matt Benson" <gu...@gmail.com> a écrit :
> AFAIK Mark Struberg's work on the OWB proxies could be instructive, and
> since I've just spent several weeks in ASM hell I might just be a bit of
> use there myself. The only thing is, isn't cglib built on ASM as well? The
> dynamic nature of the various proxy helpers means that we probably couldn't
> really improve on cglib, i.e. only if we could test invocation matching up
> front while creating the proxy class would we be faster.
>
> Matt
> On Jul 27, 2013 12:22 PM, "Romain Manni-Bucau" <rm...@gmail.com>
> wrote:
>
> > Hehe, we benched in owb but lets wait the porting ;)
> > Le 27 juil. 2013 16:49, "James Carman" <ja...@carmanconsulting.com> a
> > écrit :
> >
> > > On Sat, Jul 27, 2013 at 10:34 AM, Romain Manni-Bucau
> > > <rm...@gmail.com> wrote:
> > > > Once ill have done the monitoring stuff ill try to work on it.
> > >
> > > What would be really cool is to have a "smackdown" once we get ASM
> > > into the mix to see which one performs the best and exactly how fast
> > > they are compared to one another.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > > For additional commands, e-mail: dev-help@commons.apache.org
> > >
> > >
> >
>
Re: [proxy] and impl
Posted by Matt Benson <gu...@gmail.com>.
AFAIK Mark Struberg's work on the OWB proxies could be instructive, and
since I've just spent several weeks in ASM hell I might just be a bit of
use there myself. The only thing is, isn't cglib built on ASM as well? The
dynamic nature of the various proxy helpers means that we probably couldn't
really improve on cglib, i.e. only if we could test invocation matching up
front while creating the proxy class would we be faster.
Matt
On Jul 27, 2013 12:22 PM, "Romain Manni-Bucau" <rm...@gmail.com>
wrote:
> Hehe, we benched in owb but lets wait the porting ;)
> Le 27 juil. 2013 16:49, "James Carman" <ja...@carmanconsulting.com> a
> écrit :
>
> > On Sat, Jul 27, 2013 at 10:34 AM, Romain Manni-Bucau
> > <rm...@gmail.com> wrote:
> > > Once ill have done the monitoring stuff ill try to work on it.
> >
> > What would be really cool is to have a "smackdown" once we get ASM
> > into the mix to see which one performs the best and exactly how fast
> > they are compared to one another.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
Re: [proxy] and impl
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hehe, we benched in owb but lets wait the porting ;)
Le 27 juil. 2013 16:49, "James Carman" <ja...@carmanconsulting.com> a
écrit :
> On Sat, Jul 27, 2013 at 10:34 AM, Romain Manni-Bucau
> <rm...@gmail.com> wrote:
> > Once ill have done the monitoring stuff ill try to work on it.
>
> What would be really cool is to have a "smackdown" once we get ASM
> into the mix to see which one performs the best and exactly how fast
> they are compared to one another.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [proxy] and impl
Posted by James Carman <ja...@carmanconsulting.com>.
On Sat, Jul 27, 2013 at 10:34 AM, Romain Manni-Bucau
<rm...@gmail.com> wrote:
> Once ill have done the monitoring stuff ill try to work on it.
What would be really cool is to have a "smackdown" once we get ASM
into the mix to see which one performs the best and exactly how fast
they are compared to one another.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [proxy] and impl
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Once ill have done the monitoring stuff ill try to work on it.
Le 27 juil. 2013 16:06, "James Carman" <ja...@carmanconsulting.com> a
écrit :
> While I get what you're saying, that's kind of the entire reason
> Commons Proxy was created. Proxy came about from my experience with
> Apache HiveMind and Javassist. We were constantly doing Javassist
> coding each time we wanted new proxying logic. There was a LOT of
> repeated code because of all the commonality. After a couple years of
> doing this, I decided to create a library which would consolidate that
> logic into one library and allow the user to provide small "snippets"
> (Interceptors, Invokers, ObjectProvider) to achieve what they wanted
> to do.
>
> You're right, Commons Proxy doesn't really fit in Apache Commons
> perfectly, since it is very "frameworky", but we decided to roll it in
> anyway.
>
> Anyway, so much for a history lesson. :) I have wanted an ASM-based
> proxy factory for a long time, but have just never had the time to get
> around to it. If you want to help us create an ASM-based proxy
> factory implementation, that would be great! I'm no ASM expert, so I
> wouldn't even know where to start.
>
> On Sat, Jul 27, 2013 at 9:51 AM, Romain Manni-Bucau
> <rm...@gmail.com> wrote:
> > Hi
> >
> > On a mail on [monitoring] i put some point on proxy. The main question
> was
> > shouldnt proxy give a default impl of proxying instead of being a facade
> > (which needs to put all impl specifities in the api or a way to get
> them)?
> >
> > In tomee/openejb and owb we use asm to create proxies and
> InvocationHandler
> > standard interface. That's very powerful and insanely fast.
> >
> > Asm also provides some helpers like
> >
> http://asm.ow2.org/asm40/javadoc/user/org/objectweb/asm/commons/AdviceAdapter.html
> .
> >
> > My question is then: shouldnt proxy2 change a bit of spirit?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [proxy] and impl
Posted by James Carman <ja...@carmanconsulting.com>.
While I get what you're saying, that's kind of the entire reason
Commons Proxy was created. Proxy came about from my experience with
Apache HiveMind and Javassist. We were constantly doing Javassist
coding each time we wanted new proxying logic. There was a LOT of
repeated code because of all the commonality. After a couple years of
doing this, I decided to create a library which would consolidate that
logic into one library and allow the user to provide small "snippets"
(Interceptors, Invokers, ObjectProvider) to achieve what they wanted
to do.
You're right, Commons Proxy doesn't really fit in Apache Commons
perfectly, since it is very "frameworky", but we decided to roll it in
anyway.
Anyway, so much for a history lesson. :) I have wanted an ASM-based
proxy factory for a long time, but have just never had the time to get
around to it. If you want to help us create an ASM-based proxy
factory implementation, that would be great! I'm no ASM expert, so I
wouldn't even know where to start.
On Sat, Jul 27, 2013 at 9:51 AM, Romain Manni-Bucau
<rm...@gmail.com> wrote:
> Hi
>
> On a mail on [monitoring] i put some point on proxy. The main question was
> shouldnt proxy give a default impl of proxying instead of being a facade
> (which needs to put all impl specifities in the api or a way to get them)?
>
> In tomee/openejb and owb we use asm to create proxies and InvocationHandler
> standard interface. That's very powerful and insanely fast.
>
> Asm also provides some helpers like
> http://asm.ow2.org/asm40/javadoc/user/org/objectweb/asm/commons/AdviceAdapter.html.
>
> My question is then: shouldnt proxy2 change a bit of spirit?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org