Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
framework-2.0.0
-
None
Description
[ from http://markmail.org/message/pu5usr5s7vsweyv3 ]
I think there's a bug in our ServiceReference.isAssignableTo implementation...
the javadoc for this method states:
"This method performs the following checks:
1. Get the package name from the specified class name.
2. For the bundle that registered the service referenced by this ServiceReference (registrant bundle);
find the source for the package. If no source is found then return true if the registrant bundle is
equal to the specified bundle; otherwise return false.
3. If the package source of the registrant bundle is equal to the package source of the specified
bundle then return true; otherwise return false."
whereas our implementation does:
// There are three situations that may occur here:
// 1. The requester does not have a wire for the package.
// 2. The provider does not have a wire for the package.
// 3. Both have a wire for the package.
// For case 1, we do not filter the service reference since we
// assume that the bundle is using reflection or that it won't
// use that class at all since it does not import it. For
// case 2, we have to try to load the class from the class
// loader of the service object and then compare the class
// loaders to determine if we should filter the service
// refernce. In case 3, we simply compare the exporting
// modules from the package wiring to determine if we need
// to filter the service reference.
assume both the provider and requester have no wire for the package
(as happens when a bundle uses it's own export, as in this situation)
the javadoc says isAssignableTo should return false, because the
provider has no wire and the provider != requester - but we'll return
true because the requester has no wire and we do that check first