Hi Guillaume, There are 3 kinds of proxy support currently available in the proxy bundle. They are used in this order, falling back to the next level if the conditions are not met: 1. Weaving proxy (if OSGi level is 4.3 i.e. WeavingHooks are supported and ASM is available) - can proxy just about anything 2. ASM subclass proxy (if ASM is available) - can't proxy any final classes or classes with final methods 3. JDK default proxy - can only proxy interfaces
Currently the behaviour of the weaving proxy is to register the OSGi WeavingHook and then weave all classes subsequently loaded. The weaving has to be done at class load time and we can't identify which classes might need a proxy until after they have already been loaded, which leads to difficulties if we don't weave everything. In addition to the increase flexibility of being able to proxy "finals" the woven class proxy objects have very significant performance benefits over the sub-class and JDK proxies during invocations. The weaving of just sub-classes is not as benign as it might seem because although there is a cache of the generated sub-classes they may be frequently regenerated depending on the number of proxies used. It is difficult to balance the up-front weaving cost against run time performance improvements and as with all performance it is scenario dependent and difficult to please everyone. There was some discussion on this list a while back about including an optional list of packages to exclude from weaving to provide more customisation over what was woven, but I don't believe anyone ever raised a JIRA for it. Perhaps this might provide an avenue for you to avoid weaving as much? Rich From: Guillaume Nodet <[email protected]> To: [email protected] Date: 18/11/2011 16:45 Subject: Re: Proxy weaving On Fri, Nov 18, 2011 at 15:40, Timothy Ward <[email protected]> wrote: > > Hi Guillaume, > > Isn't ASM an optional dependency for the proxy component already? Without > ASM you get slower, interface only, proxy support but it's still fine for > blueprint to use if you don't want to install the ASM bundle. > > What's the difference between the asm proxy and the woven classes ? it seems to me much slower to weave all classes loaded instead of subclassing the few that will actually be needed. Is that really how that's supposed to behave ? > I'm not wild about pushing proxying function into blueprint, the bundle > already does a lot, and in my opinion it is at risk of becoming bloated if > we keep adding more things to it. One of the great things about OSGi is > that we can share this stuff more easily, I think having a single proxy > service used by Blueprint, JNDI and EJB is a really good example of how > bundles should work. > > Regards, > > Tim Ward > ------------------- > Apache Aries PMC member & Enterprise OSGi advocate > Enterprise OSGi in Action (http://www.manning.com/cummins) > ------------------- > > > > Date: Fri, 18 Nov 2011 14:03:34 +0100 > > Subject: Re: Proxy weaving > > From: [email protected] > > To: [email protected] > > > > Btw, it seems something has been broken by ARIES-468 a long time ago. > > Previously, using class proxies was requiring to use the ext namespace > > handler, because such a behavior was outside the spec. It seems to not > be > > the case anymore, meaning I suppose our implementation is not compliant > > anymore (unless I missed a spec relax on that point). > > > > I'm mostly referring to > > > https://github.com/apache/aries/commit/24455ce2f04fbdfd207e5953bb6d87b2963eb9d4#diff-5which > > remove all the references to the ext:proxy-method="class" . > > > > Also, since this behavior is outside the spec, I'd like to be able to get > > back blueprint running without asm + proxy, so that class proxying would > be > > optional and only available when proxy + asm is present (proxy becoming > an > > optional imported package). > > > > On Fri, Nov 18, 2011 at 12:08, Guillaume Nodet <[email protected]> wrote: > > > > > It seems when I deploy the new proxy manager, all classes are woven > which > > > is very costly in terms of cpu (nearly 45% of Karaf startup time). > > > Why is that necessary ? Without seing any benefits, I'm not really > > > prepared to pay that cost. > > > Any ideas ? > > > > > > -- > > > ------------------------ > > > Guillaume Nodet > > > ------------------------ > > > Blog: http://gnodet.blogspot.com/ > > > ------------------------ > > > Open Source SOA > > > http://fusesource.com > > > > > > > > > > > > -- > > ------------------------ > > Guillaume Nodet > > ------------------------ > > Blog: http://gnodet.blogspot.com/ > > ------------------------ > > Open Source SOA > > http://fusesource.com > > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
