My initial problem is the cost of weaving *all* classes loaded by the osgi framework.
My second problem is the fact that the implementation does not follow the spec and that the ext:proxy-method attribute is now broken. Minimizing the blueprint core dependencies by making proxy optional (for supporting the class proxying which is not mandated) is a third point which isn't related. Any thoughts on the two first point ? 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. > > 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
