commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: [proxy] and impl
Date Mon, 29 Jul 2013 14:59:30 GMT
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 <gudnabrsam@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 <gudnabrsam@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 <rmannibucau@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" <gudnabrsam@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
>>>>>> > > <rmannibucau@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
>>>>>> > >
>>>>>> > >
>>>>>> >
>>>>>>
>>>>>
>>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message