Ok, I think we're getting to the crux of my misunderstanding. To my
mind stopping when there are not wires is dangerous because the other
bundle could still technically load an interface with the same name
from its classloader even if there are no wires and, so, you will get
a class cast exception.
Now, you state "we assume reflection is being used if the consuming
bundle is not wired to the package of the service class". Can you
explain what this means?
Regards,
Alan
On Apr 15, 2009, at 6:57 AM, Thomas Watson wrote:
Equinox behaves the same as Felix here.
Personally I find the term "not incompatible" hard to understand in
section 5.9.1. Seem "not incompatible" is just "compatible".
Section 6.1.23.6 is the JavaDoc for isAssignableTo() but I don't
think it necessarily reflects the intent of section 5.9.1. By "last
sentence" I assume you mean the sentence in 5.9.1 "That is, it is
either wired to the same source
class loader or it has no wire for that package at all.". For the
case where the consuming bundle is not wired to the package at all
it is "compatible" with the service because it can never cast that
service to the service type. The point of this method is to avoid
ClassCastExceptions in the consuming bundle. As Richard points out
we assume reflection is being used if the consuming bundle is not
wired to the package of the service class.
Tom
<graycol.gif>"Alan D. Cabrera" ---04/14/2009 10:26:23 PM---The
JavaDoc reflects section 6.1.23.6 and more accurately reflects the
intent of section 5.9.1. That last sentence, to my mind
<ecblank.gif>
From: <ecblank.gif>
"Alan D. Cabrera" <[email protected]>
<ecblank.gif>
To: <ecblank.gif>
OSGi Developer Mail List <[email protected]>
<ecblank.gif>
Date: <ecblank.gif>
04/14/2009 10:26 PM
<ecblank.gif>
Subject: <ecblank.gif>
Re: [osgi-dev] isAssignableTo() and the system bundle
The JavaDoc reflects section 6.1.23.6 and more accurately reflects
the intent of section 5.9.1. That last sentence, to my mind, is just
plain inaccurate and dangerous.
Regards,
Alan
On Apr 14, 2009, at 8:13 PM, Richard S. Hall wrote:
Maybe the JavaDoc needs to be updated to more closely resemble the
spec text.
-> richard
On 4/14/09 10:44 PM, Stuart McCulloch wrote:
2009/4/15 Richard S. Hall <[email protected]>
I think you are not correct.
If a bundle has no wire to the package, which system bundle
shouldn't since it cannot import, then it should get back all
service references. I think the spec assumes you are using
reflection if you have no wire to the package. I cannot remember if
this behavior is spec'ed some place but I thought so. At least
that's what we do in Felix (and Equinox, I believe).
ah... 5.9.1 of the core spec:
"The service registry must therefore ensure that bundles can only
see services that are not
incompatible with them. A service is not incompatible with the
bundle getting the service when
that bundle is not wired to another source class loader for this
interface package than the
bundle registering the service. That is, it is either wired to the
same source class loader or
it has no wire for that package at all."
but I think Alan has a point that if you read the javadoc for
ServiceReference.isAssignableTo()
it does seem to apply a stronger rule: that is it returns true if
both bundles use the same source
for the package, otherwise false
so if the bundle providing the service has a wire, and the bundle
using the service doesn't have
a wire, does that mean they use the "same source" for the package?
(isAssignableTo() == true)
-> richard
On 4/14/09 8:09 PM, Alan D. Cabrera wrote:
After reading the core spec it seems that if I look for service
using the system bundle context, I will never be able to find any
application specific service. Let me explain my reasoning and maybe
someone can show me where my disconnect is occurring.
Upon reading the definition of the getServiceReferences() method I
see that isAssignableTo() must be called with all the service
interfaces and the bundle that is being used to perform the "call"
to getServiceReferences().
It seems to me that if I pass the system bundle to isAssignableTo()
I will get false for just about all the application specific service
interfaces.
If that is true then it seems that I will not be able to retrieve
most service references with the system bundle.
Am I correct?
Regards,
Alan
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Cheers, Stuart
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
