Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (herse.apache.org: domain of rajinisivaram@googlemail.com
 designates 64.233.166.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=TOh6/njvYrDlL7KISDm7Qoy/jwGOQq+x5KW4qby4XIjyfBdf2oZc5QU7WKAtKLL3EYTX1bMhDC5nbQmO2on59YhXwQ0PYOAJnCuwNGE/q2CJY2aNwHTsMKd3UFOCvDfOgkZ0eZhLHo2IWALkgwh2Tmvs42l50a7HqQNBXinTau0=
Message-ID: <a440eccf0706180554jc135e8m4b2ce9297b9eb3ca@mail.gmail.com>
Date: Mon, 18 Jun 2007 13:54:31 +0100
From: "Rajini Sivaram" <rajinisivaram@googlemail.com>
To: dev@felix.apache.org
Subject: Re: Implementation of ServiceReference.isAssignableTo different in
 various OSGi framework implementations
In-Reply-To: <46767955.5030704@ungoverned.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_20246_28536846.1182171271291"
References: <a440eccf0706150909x2c0ef4fcy37d723bddb3e5316@mail.gmail.com>
	 <4672D751.7090809@ungoverned.org>
	 <a440eccf0706180055i182648ffsd92b90713e474bc1@mail.gmail.com>
	 <46767955.5030704@ungoverned.org>

------=_Part_20246_28536846.1182171271291
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Richard,

Yes, you are right. With DS, the bundle wont have access to the class, so
the first test wont cause the same problem.

If you do put the fix in, when will it be available in a Felix release? Is
there a new release planned soon?

Thank you...

Regards,

Rajini


On 6/18/07, Richard S. Hall <heavy@ungoverned.org> wrote:
>
> Rajini Sivaram wrote:
> > Thank you, Richard. The fix will be of great help to me.
> >
> > I imagine that the first check will need to be removed to support
> delayed
> > services with Declarative Services for Felix since presumably DS also
> > installs proxy services in order to implement delayed services.
>
> Proxies are not needed in DS because it can just use the ServiceFactory
> interface...
>
> Even then, it seems that your scenario is only relevant if the registrar
> also has access to the same class of the provider's service object,
> right? In general, DS, for example, would not have access to any service
> object interfaces so the first check would always fail and the second
> test would be used. At least, that is my understanding.
>
> I haven't committed the changes yet, but I should be the end of the day,
> I imagine...I just want to think about it a little bit more before doing
> so...
>
> Thanks again.
>
> -> richard
>
> >
> > Thank you...
> >
> > Regards,
> >
> > Rajini
> >
> >
> > On 6/15/07, Richard S. Hall <heavy@ungoverned.org> wrote:
> >>
> >> Rajini Sivaram wrote:
> >> > Hello,
> >> >
> >> > I am working on SCA-OSGi integration to enable OSGi bundles to form
> >> the
> >> > implementation type for Apache Tuscany SCA components. I have run
> into
> >> > some
> >> > problems because of the way service references are filtered in Felix.
> >> >
> >> > This is the scenario. We startup Felix runtime in embedded mode
> inside
> >> > Tuscany. To intercept an OSGi service, a proxy is registered into the
> >> > OSGi
> >> > service registry. The interface used by the proxy is of the same
> >> > classloader
> >> > as the one seen by the requestor bundle (it was loaded using
> >> > requestorBundle.loadClass). The classloader of the system bundle
> >> > however has
> >> > access to this interface loaded by the application classloader. The
> >> > requestor has a wire for the interface, but the provider (system
> >> bundle)
> >> > doesn't. The test performed for ServiceReference.isAssignableTo seems
> >> > to be
> >> > different for Equinox, Knopflerfish and Felix. In both Equinox and
> >> > Knopflerfish, the proxy service is returned to the requestor bundle
> >> when
> >> > getServiceReference is called. Felix, however first tests if the
> class
> >> > loaded by the provider is the same as the class loaded by the
> >> requestor
> >> (
> >> > ServiceRegistrationImpl.isClassAccessible()). If the class cannot be
> >> > loaded
> >> > by the provider, then the class of the registered object is tested.
> Is
> >> > the
> >> > first test which prevents bundles from registering services of
> objects
> >> > using
> >> > different classloaders strictly necessary? Wouldn't it be sufficient
> >> > to test
> >> > the class of the object registered?
> >>
> >> Yes, you could be right, because if the service object class is loaded
> >> from the provider, then it should be discovered by the second check
> >> anyway, right? Thus, it seems like it should only be necessary to do
> the
> >> second check which will cover both cases...I think... :-)
> >>
> >> Anyone want to venture a guess as to whether my logic is correct? If
> so,
> >> I can commit a fix...
> >>
> >> -> richard
> >>
> >>
> >
>

------=_Part_20246_28536846.1182171271291--