Actually and to be clear, the third point only came to my mind if there's no way to disable #1 Relying on ASM bundle not being installed is out of my control for a platform such as Karaf where other bundles might actually need ASM.
On Fri, Nov 18, 2011 at 16:13, Guillaume Nodet <[email protected]> wrote: > 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 > > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
