尽管OSGi在Java世界中越来越流行，但仍有许多Java应用程序和库尚未设计成可在OSGi中使用。 有时您可能需要在OSGi环境中运行这样的代码，或者是因为您想利用OSGi本身提供的好处，或者因为您需要仅由该特定环境提供的某些功能。 通常，您负担不起完全迁移到OSGi的负担，或者至少需要一个过渡期，在此期间，您的代码在OSGi内外均可以正常工作。 当然，您希望以最小的努力做到这一点，而又不会增加软件的复杂性。

最近，我们在SAP的团队面临着类似的挑战。 我们有一个相当大的遗留普通Java应用程序，多年来，它已发展为包括许多本地框架和自定义解决方案。 我们需要为此应用程序提供基于REST的接口，因此我们要么必须包含Web服务器，要么必须在具有该Web服务器的环境中运行。 我们选择使用SAP Lean Java Server（LJS） ，后者是SAP NetWeaver Cloud背后的引擎，其中包括Tomcat和其他有用的服务。 但是，LJS基于Eclipse的OSGi实现Equinox ，因此我们需要确保我们的代码与OSGi兼容，以确保流畅的互操作性。 在此过程中，我们学到了很多有关该主题的知识，因此我想在本文中与您分享我们最有趣的发现。

为了使纯Java代码在OSGi环境中顺利运行，应满足以下先决条件：

• 它打包为OSGi捆绑包 ，即具有有效OSGi清单的jar存档。
• 它遵守OSGi对动态加载类施加的要求和限制。
• 它的所有软件包仅由一个捆绑软件导出，即没有不同的捆绑软件导出同一软件包。

同样，在许多情况下，您可能需要为要从OSGi控制台启动的应用程序创建新的入口点。 如果使用Equinox，则应考虑为此目的创建一个Equinox应用程序。

请注意，满足以上要求既不意味着您不应该以任何方式将代码迁移到OSGi，使其仅在OSGi中运行，也不意味着您应从根本上将开发环境或过程更改为基于OSGi。 相反，我们的经验表明，通过以下列方式满足上述要求，很可能实现与OSGi的兼容性 ，而不会失去在OSGi外部运行的能力，并且不会显着改变您的开发方法和工具：

• 可以使用BND和其他基于它的工具自动生成所有OSGi清单。 在OSGi之外，不使用这些清单，但也不会造成伤害。
• 基于Class.forName()动态加载类和自定义类加载可以由使用引擎盖下本机OSGi服务的几乎相同的机制代替。 可以根据您的代码是否在OSGi中执行而在原始和OSGi机制之间动态切换，而对现有代码的更改很少。
• 另外，通过使用OSGi服务机制动态注册和发现“命名”实现，您可以完全摆脱OSGi中的动态类加载。
• 由多个捆绑软件导出的相同软件包应该简单地重命名。 显然，这也适用于OSGi。
• 通过将所有特定于OSGi的代码放在有限数量的包中，可以最大程度地减少对OSGi的依赖性，这些包最好也不包含应在OSGi外部执行的代码。

以下各节提供有关如何实现的更多详细信息。

包装为OSGi捆绑包

为了在OSGi环境中工作，所有Java代码都应打包为OSGi捆绑包。 这不仅适用于由构建生成的所有存档，还适用于作为软件的一部分提供的所有依赖项。

如果您的构建使用Maven，则应强烈考虑使用Maven Bundle插件 （内部使用BND）为该构建生成的所有档案生成有效的OSGi清单。 在大多数情况下，由该插件的默认配置生成的清单将可以正常工作。 但是，在某些情况下，可能需要进行一些细微的调整和添加才能生成正确的清单，例如：

• 为仅通过反射使用的类添加其他导入包，因此BND无法找到。
• 为公开OSGi声明性服务的分发包指定服务组件XML。
• 为依赖于自定义激活的捆绑软件指定捆绑软件激活器。

在我们的项目中，如下所述，在我们的父POM中配置了bundle插件：

<properties><classpath></classpath><import-package>*</import-package><export-package>{local-packages}</export-package><bundle-directives></bundle-directives><bundle-activator></bundle-activator><bundle-activationpolicy></bundle-activationpolicy><require-bundle></require-bundle><service-component></service-component>...
</properties>
...
<build><pluginManagement><plugins><plugin><groupId>org.apache.felix</groupId><artifactId>maven-bundle-plugin</artifactId><version>2.3.4</version><extensions>true</extensions><configuration><encoding>${project.build.sourceEncoding}</encoding><archive> <forced>true</forced> </archive><instructions><Bundle-SymbolicName>${project.artifactId}${bundle-directives}</Bundle-SymbolicName><Bundle-Name>${project.artifactId}</Bundle-Name><_nouses>true</_nouses><Class-Path>${classpath}</Class-Path><Export-Package>${export-package}</Export-Package><Import-Package>${import-package}</Import-Package><Bundle-Activator>${bundle-activator}</Bundle-Activator><Bundle-ActivationPolicy>${bundle-activationpolicy}</Bundle-ActivationPolicy><Require-Bundle>${require-bundle}</Require-Bundle><Service-Component>${service-component}</Service-Component></instructions></configuration><executions><execution><id>bundle-manifest</id><phase>process-classes</phase><goals><goal>manifest</goal></goals></execution></executions></plugin>...</plugins></pluginManagement>
</build>

在子POM中，我们指定任何需要具有与默认值不同的值的属性。 在我们的案例中，这种POM相对较少。

我们的大多数依赖项也没有OSGi清单，因此我们在构建过程中生成它们。 当前，这是通过使用BND wrap命令的Groovy脚本完成的。 对于我们的大多数依赖项，对清单使用通用模板就足够了。 当前，我们使用以下模板，该模板由脚本动态生成：

Bundle-Name: ${artifactId}
Bundle-SymbolicName: ${artifactId}
Bundle-Version: ${version}
-nouses: true
Export-Package: com.sap.*;version=${version_space},*
Import-Package: com.sap.*;version="[${version_space},${version_space}]";resolution:=optional,*;resolution:=optional

一世
仅在少数情况下，清单模板必须包含特定于混凝土罐的信息。 我们通过在SCM中提交这些模板并使用提交的版本而不是默认版本来捕获这些细节。

符合OSGi类加载

常用的类加载机制的替代方法

OSGi环境强加了自己的类加载机制，以下文章中对此进行了详细描述：

• OSGi类加载
• OSGi中的类加载和类型可见性

但是，一些普通的Java应用程序和库通常广泛依赖于创建自定义类加载器并通过Class.forName()或ClassLoader.loadClass()加载类，以使用反射 ，我们的应用程序就是其中之一。 这在OSGi中是有问题的，如《 OSGi准备就绪-加载类》中更详细描述。 本文提出的解决方案虽然有效，但不能直接应用于我们的案例，因为这将涉及大量更改旧代码，这是我们目前不希望做的事情。

我们发现，可以完全依靠本机OSGi机制以优雅的方式解决此问题，对于我们的大部分遗留代码而言都是透明的。 代替Class.forName() ，可以使用以下调用顺序：

• 使用FrameworkUtil.getBundle()获取当前的Bundle及其BundleContext 。
• 通过上一步中获得的捆绑包上下文从OSGi服务注册表中获取标准PackageAdmin服务
• 使用PackageAdmin.getExportedPackage()和ExportedPackage.getExportingBundle()查找ExportedPackage.getExportingBundle() Bundle包。
• 最后，只需调用Bundle.loadClass()即可加载请求的类。

另外，尽管不可能直接使用低级别的捆绑包类加载器，但捆绑包类本身提供了诸如Bundle.loadClass()和Bundle.getResource()类的类加载方法。 因此，可以创建一个自定义的类加载器，该类加载器包装一个包（或多个包）并委托给这些方法。

要使您的大部分遗留代码在OSGi中工作，而只需进行少量更改，就可以通过以下方式对其进行调整：

• 如果代码在OSGi中执行，则代替调用Class.forName() ，而调用实现上述序列的方法。
• 如果代码在OSGi中执行， BundleClassLoader要从多个jar文件中创建自定义类加载器，而BundleClassLoader与这些jar文件相对应的BundleClassLoader包中创建BundleClassLoader 。

为了使上述更改更加直接，我们在应用程序中引入了一个名为ClassHelper的新类。 它是一个单例，提供以下静态助手方法，这些方法委托给单个实例的相同非静态方法：

public static boolean isOsgi();
public static Object getBundleContext(Class<?> clazz);
public static Class<?> forName(String className, ClassLoader cl) throws ClassNotFoundException;
public static ClassLoader getBundleClassLoader(String[] bundleNames, ClassLoader cl);

这些方法的默认实现在基本ClassHelper类中实现了默认的非OSGi行为– isOsgi()返回false， getBundleContext()和getBundleClassLoader()返回null， forName()只是委托给Class.forName() 。

OsgiClassHelper类继承自ClassHelper并依次实现上述正确的OSGi行为。 我们将该类放在其自己的特殊捆绑包中，以确保包含ClassHelper和大量其他实用程序的捆绑包不受OSGi依赖关系的影响。 这个特殊的捆绑有一个Activator ，它取代了默认ClassHelper用一个实例OsgiClassHelper在束激活实例。 由于激活代码仅在OSGi中执行，因此可以确保在两种情况下均加载正确的实现。

在我们其余的代码中， ClassHelper.forName()替换Class.forName()调用，并使用ClassHelper.forName()创建自定义类加载器就ClassHelper.getBundleClassLoader() 。

使用OSGi服务

在许多普通的Java应用程序中，某些实现是基于字符串“ handle”（类名本身或其他名称）加载的。 通常将ClassLoader.loadClass()与自定义类加载结合使用，通常用于此目的。 OSGi提供了OSGi服务机制，用于注册和发现此类“命名”的实现，这将使您完全摆脱动态类加载。 此机制是OSGi固有的，它为上述自定义机制提供了非常优雅的替代方法。 与上一节中介绍的方法相比，此方法的缺点是，它需要对代码进行一些更深的更改，特别是如果它也应继续在OSGi之外运行的话。

您需要考虑以下方面：

• 在OSGi服务注册表中注册您的接口和实现。
• 在运行时在使用它们的代码中发现这些实现。

尽管您可以通过编程方式注册服务，但在大多数情况下，您还是希望使用OSGi声明式服务方法，因为它允许以纯声明性的方式将现有实现注册为OSGi服务。 关于发现，您可以直接通过BundleContext提供的功能查询服务注册表，也可以使用功能更强大的服务跟踪器机制 。
关于OSGi服务，尤其是声明式服务，有很多很棒的教程，其中包括：

• OSGi服务– Lars Vogel的教程 。
• OSGi入门： Neil Bartlett的声明式服务简介 。

就我们而言，我们不想太大地改变我们的代码库，因此我们只在少数几个我们认为积极影响可以证明投资合理的地方改用OSGi服务。 目前，我们通过添加服务组件XML将现有的实现声明为服务。 尽管这种基于XML的方法是标准且常用的方法，但我们发现它相当冗长且不便。 另一种方法是使用注释来指定组件和服务，如声明性服务Wiki页面和OSGi Release 4 Draft Paper中所述 。 BND已经支持这些注释。

其他注意事项

所有包装仅以一捆出口

从多个捆绑包中导出同一软件包在OSGi中效果不佳，因此必须避免。 如果您的代码中包含这种情况，则应适当地重命名这些软件包。

公开OSGi入口点

最后，您可能需要提供一个新的入口点，以便从OSGi控制台启动您的应用程序。 如果使用Equinox，则一种合适的机制是创建一个Equinox应用程序 ，该应用程序包括实现org.eclipse.equinox.app.IApplication接口并提供一个附加的plugin.xml，如Eclipse插件入门：命令中所述。在线应用程序 。 可以使用startApp命令从Equinox OSGi控制台启动此应用程序。

结论

通过遵循本文中介绍的准则和方法，可以使普通的Java应用程序和库OSGi兼容，而对您现有代码的投入却相对较小，而且可管理。

您在使Java代码与OSGi兼容方面有类似的经验吗？ 如果是的话，我很想听听。

参考：通过我们的JCG合作伙伴 Stoyan Rachev的Stoyan Rachev博客博客，可以使Java Old Java OSGi兼容 。

翻译自: https://www.javacodegeeks.com/2012/11/making-plain-old-java-osgi-compatible.html