网站建设总结会上 领导讲话稿,公司网站建设费用科目,建设银行官方网站首页,移动开发应用尽管OSGi在Java世界中越来越流行#xff0c;但仍有许多Java应用程序和库尚未设计成可在OSGi中使用。 有时您可能需要在OSGi环境中运行这样的代码#xff0c;或者是因为您想利用OSGi本身提供的好处#xff0c;或者因为您需要仅由该特定环境提供的某些功能。 通常#xff0c;… 尽管OSGi在Java世界中越来越流行但仍有许多Java应用程序和库尚未设计成可在OSGi中使用。 有时您可能需要在OSGi环境中运行这样的代码或者是因为您想利用OSGi本身提供的好处或者因为您需要仅由该特定环境提供的某些功能。 通常您负担不起完全迁移到OSGi的负担或者至少需要一个过渡期在此期间您的代码在OSGi内外均可以正常工作。 当然您希望以最小的努力做到这一点而又不会增加软件的复杂性。 最近我们在SAP的团队面临着类似的挑战。 我们有一个相当大的遗留普通Java应用程序多年来它已发展为包括许多本地框架和自定义解决方案。 我们需要为此应用程序提供基于REST的接口因此我们要么必须包含Web服务器要么必须在具有该Web服务器的环境中运行。 我们选择使用SAP Lean Java ServerLJS 后者是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插件 propertiesclasspath/classpathimport-package*/import-packageexport-package{local-packages}/export-packagebundle-directives/bundle-directivesbundle-activator/bundle-activatorbundle-activationpolicy/bundle-activationpolicyrequire-bundle/require-bundleservice-component/service-component...
/properties
...
buildpluginManagementpluginsplugingroupIdorg.apache.felix/groupIdartifactIdmaven-bundle-plugin/artifactIdversion2.3.4/versionextensionstrue/extensionsconfigurationencoding${project.build.sourceEncoding}/encodingarchive forcedtrue/forced /archiveinstructionsBundle-SymbolicName${project.artifactId}${bundle-directives}/Bundle-SymbolicNameBundle-Name${project.artifactId}/Bundle-Name_nousestrue/_nousesClass-Path${classpath}/Class-PathExport-Package${export-package}/Export-PackageImport-Package${import-package}/Import-PackageBundle-Activator${bundle-activator}/Bundle-ActivatorBundle-ActivationPolicy${bundle-activationpolicy}/Bundle-ActivationPolicyRequire-Bundle${require-bundle}/Require-BundleService-Component${service-component}/Service-Component/instructions/configurationexecutionsexecutionidbundle-manifest/idphaseprocess-classes/phasegoalsgoalmanifest/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(Classlt;?gt; clazz);
public static Classlt;?gt; 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
