[
https://issues.apache.org/jira/browse/FELIX-6697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17838171#comment-17838171
]
Tom Watson commented on FELIX-6697:
-----------------------------------
See
[https://docs.osgi.org/specification/osgi.core/8.0.0/framework.api.html#org.osgi.framework.ServiceReference.isAssignableTo-Bundle-String-]
For the specified bundle; find the source for the package. If no source is
found then return {{true}} (use of reflection is assumed by the specified
bundle).
The rules specified for this `isAssignableTo` method are the same that the
framework uses to determine if a BundleContext can get a service. This is
working as designed and the same way the Equinox Framework behaves.
> ServiceReference.isAssignableTo() allows any bundle to get access to
> unexported services from any other bundle
> --------------------------------------------------------------------------------------------------------------
>
> Key: FELIX-6697
> URL: https://issues.apache.org/jira/browse/FELIX-6697
> Project: Felix
> Issue Type: Bug
> Components: Framework
> Affects Versions: framework-3.0.0, framework-4.0.0, framework-5.0.0,
> framework-6.0.0, framework-7.0.5
> Reporter: Radu Cotescu
> Priority: Critical
>
> I was investigating some code that does a call similar to:
> {noformat}
> bundleContext.getService(bundleContext.getServiceReference("anyClassYouWant"));{noformat}
> where {{anyClassYouWant}} is indeed a service provided by a different bundle
> than the caller, but not exported. Therefore, there is no wire in between the
> two. The requester seems to get the service without any issue. This seems to
> boil down to this [0] commit:, where the thrown exception gets ignored.
>
> [0] -
> https://github.com/apache/felix-dev/commit/fd69ad6b9fd510588d858e4e06a31dee1fb59199
--
This message was sent by Atlassian Jira
(v8.20.10#820010)