On the proxying code, I did not plan to put back big chunks of code. I was just wondering about the minimal stuff, i.e. proxying for a single class, which should be at most a dozen lines of code. I think it would be beneficial in order to minize dependencies. And my idea was really to use the proxy service when available. Fwiw, I don't really plan to work on that in the short term, I'd rather have a usable 0.4.1 out asap.
On Fri, Nov 25, 2011 at 12:47, Alasdair Nottingham <[email protected]> wrote: > Hi, > > I don't think this means our implementation breaks the spec. I believe the > spec just says that an implementation is not required to support anything > but interface proxying, it doesn't ban you from doing more. If it does then > we need to take another look at this. > > I don't want to put the proxying code back into blueprint. We took it out > for a good reason (we had a ton of different bundles doing exactly the same > thing) and we should leave it independent. If we want to provide the > options you need we should do that, rather than pushing proxying back into > blueprint. > > Alasdair > > On 18 November 2011 15: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 >> > > > > -- > Alasdair Nottingham > [email protected] > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
