OSGI问题：调用getServiceReference获取服务引用返回null

1. 类加载器隔离冲突 #

OSGi的核心机制是类加载器隔离，即便两个Bundle都依赖了同一个Person接口Jar，也可能因为类加载器实例不同导致类型不匹配。你调用context.getServiceReference(Person.class)时，这里的Person.class是消费者Bundle的类加载器加载的，而注册的服务是提供者Bundle类加载器加载的Person类型——在OSGi规则里，这会被判定为两个完全不同的类型。

• 修复方式：把Person接口Jar打包成独立的OSGi Bundle，提供者和消费者Bundle都通过Import-Package声明导入该接口所在的包，不要将接口Jar分别打包进两个Bundle内部。

2. 服务注册的类名不匹配 #

检查提供者Activator的注册代码，确保服务注册时使用的类名和消费者中Person接口的全限定类名完全一致。比如注册时如果写的是context.registerService("com.example.Person", personImpl, null)，要确认消费者侧的Person接口包名、类名和这个字符串完全一致。

• 验证方法：遍历服务时，打印服务的objectClass属性值，对比它和你消费者代码中Person.class.getName()的输出是否完全相同。

3. JDK22模块系统的干扰 #

JDK22默认启用模块系统，如果Person接口所在的Jar没有声明模块，或者提供者/消费者Bundle未正确配置模块依赖，会导致类加载异常。

• 排查要点：
  • 若Person接口Jar是模块化的，检查提供者和消费者Bundle的module-info.java是否包含requires [接口模块名];声明。
  • 若接口Jar是非模块化的，确保Bundle的MANIFEST.MF里Import-Package包含接口所在包，同时确认Felix的配置未限制非模块化类的加载。

4. 服务权限或过滤条件问题 #

虽然你能遍历到服务，但getServiceReference调用可能隐含了未声明的过滤条件，或者消费者Bundle没有足够权限访问该服务。

• 排查步骤：
  • 尝试无过滤调用：context.getServiceReference((String)null)，查看返回的服务引用是否包含Person类型。
  • 检查Felix的权限配置，确保消费者Bundle拥有ServicePermission权限来获取该服务。

5. 服务注册时机不匹配 #

可能消费者Activator的start方法执行时，服务还未完成注册，导致getServiceReference返回null，但后续遍历服务时注册已经完成。

• 修复方式：改用ServiceTracker或者OSGi Declarative Services（DS）监听服务注册事件，不要在Activator启动阶段直接调用getServiceReference，确保在服务可用时再进行获取。

内容的提问来源于stack exchange，提问作者Francisco Villegas