[
https://issues.apache.org/jira/browse/FELIX-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758816#action_12758816
]
Henning Andersen commented on FELIX-1600:
-----------------------------------------
Tried to fix this locally, allow=false is not the solution. It seems to me that
case 2 is symmetrical to case 3 and implementing case using the below code
fixed the problem for our application and did not at a first glance seem to
have any negative sideeffects.
// Case 2: Only include service reference if the service
// object uses the same class as the requester.
else if (requesterWire == null)
{
// If the provider has a wire to the requestor, we are OK.
If not,
// then try to use the service registration to see if the
requester's
// class is accessible.
if (!((BundleImpl)
providerWire.getExporter().getBundle()).hasModule(requesterModule))
{
try
{
// Load the class from the requesting bundle.
Class requestClass =
requesterModule.getClassByDelegation(className);
// Get the service registration and ask it to check
// if the service object is assignable to the
requesting
// bundle's class.
allow =
getRegistration().isClassAccessible(requestClass);
}
catch (Exception ex)
{
// This should not happen, filter to be safe.
allow = false;
}
}
else
{
// O.k. the provider is wired to the requestor's
package, now check
// if the provider is wired to the latest version of
the requestor, if so
// then allow else don't (the requestor has been
updated but not refreshed).
allow = requesterModule == providerWire.getExporter();
}
}
> ServiceReference.isAssignableTo() always returns true if requesting bundle
> has no wire
> --------------------------------------------------------------------------------------
>
> Key: FELIX-1600
> URL: https://issues.apache.org/jira/browse/FELIX-1600
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: felix-2.0.0
> Reporter: Stuart McCulloch
> Fix For: felix-2.2.0
>
>
> [ 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
