Makes sense to me. Thanks for the explanation.
Regards,
Alan
On Apr 15, 2009, at 7:53 AM, Thomas Watson wrote:
When multiple versions of packages was introduced in R4.0 we came
across some scenarios where client bundles were getting service
objects and never casting them to a service type. Instead they would
just use reflection to call the service methods. In these cases the
bundle is not wired to the package for the service type. We did not
want to break these types of bundles in R4.0. You are correct that
the bundle still could load the class from its own private class
path if it is not wired to another package. But this is no different
than in OSGi R3. In R3 we did not support multiple versions of
exported packages but we still could have different bundles load
private versions of the package from their own private class path.
The introduction of isAssignableTo() in R4.0 is to solve the issues
with multiple exporters of the same package. For better or worse it
is not intended to solve the incompatibility possible from loading
classes from a bundle's private class path. That has always been a
possible issue since OSGi R1 and at the time of R4.0 the Alliance
did not feel that the issue was important enough to introduce an
incompatible change in R4.0 to address the issue.
HTH.
Tom
<graycol.gif>"Alan D. Cabrera" ---04/15/2009 09:39:38 AM---Ok, I
think we're getting to the crux of my misunderstanding. To my mind
stopping when there are not wires is dangerous becaus
<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/15/2009 09:39 AM
<ecblank.gif>
Subject: <ecblank.gif>
Re: [osgi-dev] isAssignableTo() and the system bundle
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
_______________________________________________
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
