[ 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)