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:11:11 GMT
The spec has an explicit reference to that.
In section 121.7.11

The proxies must implement all the methods that are defined in the
interface. The interface must refer to an interface, not a class. The
proxy must only support the methods in the given interface. That is,
it must not proxy methods available on the service object that are not
available in the given interface. If no interface is defined, the
proxy must be implemented as if the interface had no meth- ods
defined.

The problem has already been fixed in trunk.

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