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 <rmannibu...@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 <gudnabr...@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 < >> rmannibu...@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 <gudnabr...@gmail.com> >>> >>>> >>>> On Sun, Jul 28, 2013 at 12:16 PM, Romain Manni-Bucau < >>>> rmannibu...@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 <gudnabr...@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" <rmannibu...@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 <rmannibu...@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" <gudnabr...@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" < >>>>>>>>> rmannibu...@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 >>>>>>>>> > > <rmannibu...@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-unsubscr...@commons.apache.org >>>>>>>>> > > For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> >> >
