commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [proxy] and impl
Date Wed, 31 Jul 2013 19:44:44 GMT
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
> <rmannibucau@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 <rmannibucau@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 <gudnabrsam@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 <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
> >>>>>>>>>> > >
> >>>>>>>>>> > >
> >>>>>>>>>> >
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
> ---------------------------------------------------------------------
> 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