Re: [proxy] and impl

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 > > To: Commons Developers List > > Cc

Re: [proxy] and impl

k. LieGrue, strub - Original Message - > From: Romain Manni-Bucau > To: Commons Developers List > 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 c

Re: [proxy] and impl

can you add asm and run benchmark 10 times? *Romain Manni-Bucau* *Twitter: @rmannibucau * *Blog: **http://rmannibucau.wordpress.com/* *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau*

Re: [proxy] and impl

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 JavassistUtilsGenera

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 * *Blog: **http://rmannibucau.wordpress.com/*

Re: [proxy] and impl

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 dy

Re: [proxy] and impl

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 a

Re: [proxy] and impl

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 * *Blog: **http://rmannibucau.wordpress.com/* *LinkedIn: **http://fr.linkedin.com/in/rm

Re: [proxy] and impl

That's my point; it doesn't. On Thu, Aug 1, 2013 at 9:49 AM, James Carman wrote: > Does the ASM API require a java.lang.reflect.InvocationHandler? > > On Thu, Aug 1, 2013 at 10:41 AM, Romain Manni-Bucau > wrote: > > Well for the maintainance it is easier (and not really slower) to use a > > lit

Re: [proxy] and impl

Does the ASM API require a java.lang.reflect.InvocationHandler? On Thu, Aug 1, 2013 at 10:41 AM, Romain Manni-Bucau 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

Re: [proxy] and impl

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 * *Blog: **http://rmanni

Re: [proxy] and impl

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 int

Re: [proxy] and impl

Which code are you worried about? The checking for equals/hashcode? On Thu, Aug 1, 2013 at 10:21 AM, Romain Manni-Bucau 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

Re: [proxy] and impl

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 * *Blog: **http://rmannibucau.wordpress.com/* *LinkedIn: **http://fr.linkedin.c

Re: [proxy] and impl

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 wrote: > +1 > > jdkproxyfactory can even be hardcoded as a default IMO (without using

Re: [proxy] and impl

+1 jdkproxyfactory can even be hardcoded as a default IMO (without using the SPI) *Romain Manni-Bucau* *Twitter: @rmannibucau * *Blog: **http://rmannibucau.wordpress.com/* *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Git

Re: [proxy] and impl

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

Re: [proxy] and impl

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

Re: [proxy] and impl

On Thu, Aug 1, 2013 at 2:44 AM, Romain Manni-Bucau 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. Ba

Re: [proxy] and impl

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 createDelegatorProxy( ClassLoader classLoader, Object

Re: [proxy] and impl

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 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 > wrote: > >> Any chance

Re: [proxy] and impl

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

Re: [proxy] and impl

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 wrot

Re: [proxy] and impl

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 wrote: > Hi > > here is the asm4-shaded impl: https://gist.github.com/rmannibucau/6125125 > > *Romain Manni-Bucau* > *Twitt

Re: [proxy] and impl

Hi here is the asm4-shaded impl: https://gist.github.com/rmannibucau/6125125 *Romain Manni-Bucau* *Twitter: @rmannibucau * *Blog: **http://rmannibucau.wordpress.com/* *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: h

Re: [proxy] and impl

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 relo

Re: [proxy] and impl

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 actual

Re: [proxy] and impl

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

Re: [proxy] and impl

On Sun, Jul 28, 2013 at 12:16 PM, Romain Manni-Bucau wrote: > answers inline > > *Romain Manni-Bucau* > *Twitter: @rmannibucau * > *Blog: **http://rmannibucau.wordpress.com/* > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >

Re: [proxy] and impl

answers inline *Romain Manni-Bucau* *Twitter: @rmannibucau * *Blog: **http://rmannibucau.wordpress.com/* *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/7/28 Matt Benson > Int

Re: [proxy] and impl

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. ;-) - Woul

Re: [proxy] and impl

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 * *Blog: **http:

Re: [proxy] and impl

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" a écrit : > AFAI

Re: [proxy] and impl

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 rea

Re: [proxy] and impl

Hehe, we benched in owb but lets wait the porting ;) Le 27 juil. 2013 16:49, "James Carman" a écrit : > On Sat, Jul 27, 2013 at 10:34 AM, Romain Manni-Bucau > 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

Re: [proxy] and impl

On Sat, Jul 27, 2013 at 10:34 AM, Romain Manni-Bucau 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. -

Re: [proxy] and impl

Once ill have done the monitoring stuff ill try to work on it. Le 27 juil. 2013 16:06, "James Carman" 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 const

Re: [proxy] and impl

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 th

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