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 |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |"Alan D. Cabrera" <[email protected]> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |OSGi Developer Mail List <[email protected]> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |04/15/2009 09:39 AM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |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> <ecblank.gif> From: "Alan D. Cabrera" <[email protected]> <ecblank.gif> <ecblank.gif> To: OSGi Developer Mail List <[email protected]> <ecblank.gif> <ecblank.gif> Date: 04/14/2009 10:26 PM <ecblank.gif> <ecblank.gif> Subject: 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
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
