Well, i'd rather have a way to opt in completely. Not sure if you measure performances of weaving all classes, but in my cases, the start up time is multiplied by two, so gaining a few percent on invocations is not sufficient, especially as most of the cases i have uses only interfaces and are not even subject to class proxying, which means all the classes are woven for nothing nearly. I don't think that this is worth it, so I'd like to introduce a configuration property to somehow disable this behavior (or as I indicated earlier, have a way to use pure interface proxies from blueprint).
Just a side question. Given all woven classes now implement WovenProxy (or that's the way I read the code), do all bundles import this additional package. What happen if you refresh the proxy bundle ? On Fri, Nov 18, 2011 at 18:56, Richard Ellis <[email protected]> wrote: > 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 > > > > > > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
