OSGi 不解析 XML 插件，需由 Bundle 自行通过 bundle.getEntry("OSGI-INF/plugin.xml") 获取并解析；应在 start() 中捕获异常、记录日志、避免中断启动；Extension-Point/Extension 应替换为 OSGi 服务模型，XML 仅作元数据，实例化须走服务注册表。
OSGi 中如何识别并加载 XML 插件文件
OSGi 本身不解析 XML 插件，它只管理 Bundle（即 JAR 包）。所谓“XML 插件”，实际是 Bundle 内部携带的 XML 配置文件，由你自己的插件处理器读取。关键在于：Bundle 必须声明该 XML 资源路径（如 META-INF/plugin.xml），并在 BundleActivator.start() 或服务注册时触发解析。
常见错误是把 XML 文件放在 src/main/resources 却未确保它被正确打包进 Bundle 的根路径或指定子目录；更隐蔽的问题是未在 MANIFEST.MF 中导出含 XML 的包（Export-Package），导致其他 Bundle 无法访问——哪怕只是本 Bundle 自己读取，也建议显式导出资源所在包，避免 ClassLoader 查找失败。
- 推荐将 XML 放在
OSGI-INF/或META-INF/下，与 OSGi 标准元数据习惯一致 - 用
bundle.getEntry("OSGI-INF/plugin.xml")获取URL，比getResource()更可靠（后者受类加载委托策略影响） - 不要依赖绝对路径或
File操作——Bundle 可能是 jar 包、内存流或远程 URL
如何在 Bundle 启动时安全解析 plugin.xml
不能在 BundleActivator.start() 中直接抛出异常中断启动流程（会导致 Bundle 状态卡在 STARTING），而应捕获 XML 解析异常、记录日志，并降级为禁用该插件功能。解析逻辑建议封装为独立服务（如 PluginDescriptorService），通过 ServiceTracker 或 Declarative Services（DS）延迟加载。
public class PluginActivator implements BundleActivator {
private ServiceRegistration reg;
public void start(BundleContext ctx) throws Exception {
URL xmlUrl = ctx.getBundle().getEntry("OSGI-INF/plugin.xml");
if (xmlUrl == null) {
System.err.println("plugin.xml not found");
return;
}
try {
PluginDescriptor desc = parsePluginXml(xmlUrl.openStream());
reg = ctx.registerService(PluginDescriptorService.class, new DefaultPluginService(desc), null);
} catch (Exception e) {
// 记录完整堆栈，但不 throw
ctx.getBundle().getLogger().error("Failed to load plugin.xml", e);
}
}
private PluginDescriptor parsePluginXml(InputStream is) throws Exception {
Document doc = DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(is);
// ... 提取 extension-point / extension 元素
return new PluginDescriptor(...);
}
}
Extension-Point 和 Extension 的 OSGi 原生替代方案
传统 Eclipse RCP 的
-
Extension-Point→ 定义一个服务接口（如ReportGenerator） -
Extension→ 实现该接口的 Bundle 提供具体服务（@Component(service = ReportGenerator.class)） - 核心 Bundle 通过
ServiceTracker或ServiceReference动态发现并调用
如果仍需保留 XML 描述（例如用于 UI 动态生成菜单），XML 应仅作为元数据（比如声明 class="com.example.PdfReport"），真实实例化必须走 OSGi 服务注册表，而非反射 Class.forName() —— 后者会绕过 Bundle 类加载隔离，引发 ClassNotFoundException 或 LinkageError。
XML Schema 验证与 Bundle 版本兼容性陷阱
若多个 Bundle 共享同一份 plugin.xsd，切勿将 XSD 打包进每个 Bundle；应单独发布为一个提供 schema/ 资源的 Bundle，并由消费者 Import-Package 导入其包（如 schema.org.example.plugin）。否则会出现：
- 不同 Bundle 加载同名 XSD 时因 ClassLoader 不同而校验失败
- Schema 更新后，旧 Bundle 因缓存
SchemaFactory实例继续使用旧版本 -
DocumentBuilder默认不开启命名空间感知，导致带xmlns的 XML 解析失败
务必在解析前设置：dbf.setNamespaceAware(true)，且验证代码中显式传入 Schema 实例，而非依赖 xsi:schemaLocation 自动加载（OSGi 环境下该路径极可能不可达）。
