aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: Proxy weaving
Date Fri, 25 Nov 2011 12:21:33 GMT
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 <not@apache.org> 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 <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
>



-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Mime
View raw message