aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Nottingham <...@apache.org>
Subject Re: Proxy weaving
Date Fri, 25 Nov 2011 11:47:27 GMT
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 <gnodet@gmail.com> 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 <timothyjward@apache.org>
> 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: gnodet@gmail.com
> > > To: dev@aries.apache.org
> > >
> > > 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 <gnodet@gmail.com>
> 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
not@apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message