网站网页设计引言,做网站在线,门户网站兴化建设局,wordpress minifyosgi 模块化OSGi使Java代码可以清晰地划分为多个模块#xff0c;这些模块称为捆绑软件 #xff0c;可以访问由每个捆绑软件的类加载器控制的代码和资源。 OSGi 服务提供了一种附加的分离机制#xff1a;接口的用户无需依赖于实现类#xff0c;工厂等。 以下案例研究旨在使O… osgi 模块化 OSGi使Java代码可以清晰地划分为多个模块这些模块称为捆绑软件 可以访问由每个捆绑软件的类加载器控制的代码和资源。 OSGi 服务提供了一种附加的分离机制接口的用户无需依赖于实现类工厂等。 以下案例研究旨在使OSGi捆绑包和服务的上述优势具体化。 它采用了一个有趣的Java项目vert.x并展示了如何将其嵌入OSGi并利用OSGi的功能。 免责声明我不建议更换vert.x容器或其模块系统。 这主要是在OSGi的使用中进行的案例研究尽管某些发现应促使对vert.x进行改进尤其是将其嵌入具有自定义类加载器的应用程序中时。 版本号 vert.x开源项目提供了node.js的JVM替代方案异步事件驱动的编程模型用于以多种语言包括JavaGroovyJavaScript和Ruby编写Web应用程序。 vert.x支持HTTP以及现代协议例如WebSockets和sockjs 与WebSockets 相比 它们在更多的浏览器中工作并且可以更轻松地穿越防火墙。 vert.x具有分布式事件总线允许已知为verticles并称为busmods共享代码库vert.x应用程序之间进行传播JSON消息。 busmod是一种特殊的Verticle它处理事件总线中的事件。 vert.x附带了一些busmod例如MongoDB的 “ persistor”用户可以编写自己的。 vert.x的线程模型很有趣因为每个顶点或busmod在其生命周期内都绑定到特定线程因此顶点代码无需关注线程安全性。 线程池用于在顶点上分派工作并且每个顶点必须避免阻塞或长时间运行的操作以免影响服务器吞吐量vert.x提供了有效地实现长时间运行的操作的单独机制。 这类似于CICS事务处理器中的准可重入线程模型。 1个 这里特别受关注的是vert.x模块系统该系统每个顶点都有一个类加载器还有称为模块的代码库它们被加载到使用它们的每个顶点的类加载器中。 因此除了通过事件总线之外没有其他方法可以在各个顶点之间共享代码。 vert.x具有出色的文档包括主要手册 java手册 以及其他语言的手册 教程和可运行的代码示例 。 OSGi 如果您还不熟悉OSGi请阅读我的OSGi简介帖子但是现在不要再理会该帖子中的链接-您可以随时返回并稍后再做。 在OSGi中嵌入vert.x 我通过几个小步骤来完成此操作下面依次介绍了这些步骤将vert.x JAR转换为OSGi捆绑包然后模块化verticlebusmod和事件总线客户端。 将vert.x JAR转换为OSGi捆绑软件 vert.x手册鼓励用户使用vert.x核心JAR将vert.x嵌入自己的应用程序中因此将vert.x嵌入OSGi的第一步是将vert.x核心JAR转换为OSGi捆绑包因此可以将其加载到OSGi运行时中。 我使用了Bundlor工具尽管其他工具例如bnd也可以很好地工作。 Bundlor接受一个模板然后分析JAR的字节码以产生带有适当OSGi清单标头的新JAR。 请立即参阅SpringSource Bundlor文档以获取有关Bundlor的更多信息因为在撰写本文时Eclipse Virgo Bundlor文档尚未发布即使Bundlor项目已转移到Eclipse.org。 vert.x核心JAR的模板如下 Bundle-ManifestVersion: 2
Bundle-SymbolicName: org.vertx.core
Bundle-Version: 1.0.0.final
Bundle-Name: vert.x Core
Import-Template:org.jboss.netty.*;version[3.4.2.Final,4.0),org.codehaus.jackson.*;version[1.9.4,2.0),com.hazelcast.*;version[2.0.2,3.0);resolution:optional,groovy.*;resolution:optional;version0,org.codehaus.groovy.*;resolution:optional;version0,javax.net.ssl;resolution:optional;version0,org.apache.log4j;resolution:optional;version0,org.slf4j;resolution:optional;version0
Export-Template: *;version1.0.0.final 此案例研究的模板和所有其他部分都可以在github上找到 。 这是为JAR依赖的软件包定义有效的版本范围范围“ 0”表示0或更大的版本范围这些软件包是可选的还是强制的以及JAR自己的软件包应为哪个版本出口处。 它还为捆绑软件提供了符号名称 用于标识捆绑软件版本和描述性名称。 有了这些信息OSGi然后通过委派包类加载器之间的类加载和资源查找将包的依赖关系连接在一起。 值得庆幸的网状网络JAR和杰克逊 JSON JAR文件将vert.x核心JAR取决于附带有效的OSGi清单。 为了验证清单是否有效我尝试在处女座内核中部署vert.x核心软件包。 只需将vert.x核心软件包放置在拾取目录中并将其依赖项放置在repository / usr目录中然后启动内核即可。 以下控制台消息显示vert.x核心捆绑包已安装并成功解决 hd0001i Hot deployer processing INITIAL event for file vert.x-core-1.0.0.final.jar.
de0000i Installing bundle org.vertx.core version 1.0.0.final.
de0001i Installed bundle org.vertx.core version 1.0.0.final.
de0004i Starting bundle org.vertx.core version 1.0.0.final.
de0005i Started bundle org.vertx.core version 1.0.0.final. 然后使用处女座外壳检查线束的接线 osgi ss
Framework is launched.id State Bundle
0 ACTIVE org.eclipse.osgi_3.7.1.R37x_v20110808-1106
...
89 ACTIVE org.vertx.core_1.0.0.final
90 ACTIVE jackson-core-asl_1.9.4
91 ACTIVE jackson-mapper-asl_1.9.4
92 ACTIVE org.jboss.netty_3.4.2.Finalosgi bundle 89
org.vertx.core_1.0.0.final [89]...Exported packages...org.vertx.java.core; version1.0.0.final[exported]org.vertx.java.core.buffer; version1.0.0.final[exported]...Imported packagesorg.jboss.netty.util; version3.4.2.Finalorg.jboss.netty_3.4.2.final [92]...org.codehaus.jackson.map; version1.9.4jackson-mapper-asl_1.9.4 [91]... 我还按照以后需要的类似方式将vert.x平台JAR转换为OSGi捆绑软件。 模块化顶点 一个典型的顶点如下所示 public class ServerExample extends Verticle {public void start() {vertx.createHttpServer().requestHandler(new Handlerhttpserverrequest() {public void handle(HttpServerRequest req) {...}}).listen(8080);}
} 调用start方法时它将创建一个HTTP服务器并向该服务器注册一个处理程序并设置服务器在端口上侦听。 除了处理程序的主体之外该代码的其余部分都是样板。 因此我决定将样板分解为一个通用的OSGi捆绑包org.vertx.osgi并用包含处理程序和一些等同于样板的声明性元数据的模块化顶包来替换该竖版。 常见的OSGi捆绑包使用白板模式来侦听OSGi服务注册表中的特定种类的服务基于元数据创建样板并向生成的HTTP服务器注册处理程序。 让我们看一下模块化的vertical bundle。 它的代码包含一个HttpServerRequestHandler类 2 public final class HttpServerRequestHandler implements Handlerhttpserverrequest {public void handle(HttpServerRequest req) {...}} 它还具有服务属性形式的声明性元数据这些声明元数据与处理程序一起在OSGi服务注册表中注册。 我可以使用OSGi蓝图服务来执行此操作尽管我可以使用OSGi声明性服务甚至可以使用OSGi API以编程方式注册该服务。 蓝图元数据是捆绑软件中的文件blueprint.xml 如下所示 ?xml version1.0 encodingUTF-8?
blueprint xmlnshttp://www.osgi.org/xmlns/blueprint/v1.0.0service interfaceorg.vertx.java.core.Handler refhandlerservice-propertiesentry keytype valueHttpServerRequestHandlerentry keyport value8090/service-properties/servicebean classorg.vertx.osgi.sample.basic.HttpServerRequestHandleridhandler//blueprint 此元数据声明应创建HTTP服务器通过类型服务属性向其注册的处理程序以及侦听端口8090的服务器集通过端口服务属性。 当org.vertx.osgi捆绑包运行时这一切都是通过白板模式完成的如下所示。 请注意模块化Verticle仅依赖于Handler和HttpServerRequest类而原始Verticle也依赖于VertxHttpServer和Verticle类。 对于那些喜欢单元测试除了容器内测试的人来说这也使事情变得简单得多因为需要的模拟或存根数量更少。 那么我们现在有什么呢 将两个包添加到我们之前安装的包中一个org.vertx.osgi包它封装了样板代码一个应用程序包它代表一个模块化的verticle。 我们还需要一个Blueprint服务实现-从Virgo 3.5开始Virgo内核内置了一个Blueprint实现。 以下交互图显示了一种可能的事件序列 在OSGi中每个捆绑包都有其自己的生命周期并且通常设计捆绑包时无论它们相对于其他捆绑包启动的顺序如何它们都将正确运行。 在上面的示例中假定的启动顺序为蓝图服务org.vertx.osgi包模块化verticle包。 但是org.vertx.osgi捆绑包可以在模块化Verticle捆绑包之后开始并且最终结果将是相同的将创建服务器并且在服务器上注册模块化Verticle捆绑包的处理程序并且服务器设置监听。 如果蓝图服务是在org.vertx.osgi和模块化Verticle捆绑包之后启动的那么直到蓝图服务启动后org.vertx.osgi捆绑包才会检测到该模块化Verticle捆绑包的处理程序服务出现在服务注册表中但是最终结果将再次相同。 github项目包含一些示例模块化verticle的源代码 基本的HTTP垂直版本 在8090端口上运行和sockjs verticle 在8091端口上运行。 org.vertx.osgi捆绑软件需要更多代码来支持sockjs而模块化的sockjs verticle除了提供HTTP处理程序外还需要提供sockjs处理程序。 模块化BusMods MongoDB持久程序是处理来自事件总线的消息的busmod的典型示例 public class MongoPersistor extends BusModBase implements Handlermessagejsonobject {private String address;private String host;private int port;private String dbName;private Mongo mongo;private DB db;public void start() {super.start();address getOptionalStringConfig(address, vertx.mongopersistor);host getOptionalStringConfig(host, localhost);port getOptionalIntConfig(port, 27017);dbName getOptionalStringConfig(db_name, default_db);try {mongo new Mongo(host, port);db mongo.getDB(dbName);eb.registerHandler(address, this);} catch (UnknownHostException e) {logger.error(Failed to connect to mongo server, e);}}public void stop() {mongo.close();}public void handle(Messagejsonobject message) {...}} 同样这里混合了样板代码用于注册事件总线处理程序启动/停止逻辑配置处理以及事件总线处理程序本身。 我对其他版本应用了类似的方法并将样板代码分离到org.vertx.osgi包中将处理程序和元数据包括配置保留在模块化busmod中。 持久性对MongoDB客户端JARmongo.jar的依赖很方便因为此JAR附带了有效的OSGi清单。 这是blueprint.xml ?xml version1.0 encodingUTF-8?
blueprint xmlnshttp://www.osgi.org/xmlns/blueprint/v1.0.0service refhandler interfaceorg.vertx.java.core.Handlerservice-propertiesentry keytype valueEventBusHandler/entry keyaddress valuevertx.mongopersistor//service-properties/servicebean idhandler classorg.vertx.osgi.mod.mongo.MongoPersistordestroy-methodstopargument typejava.lang.Stringvaluelocalhost/value/argumentargument typeintvalue27017/value/argumentargument typejava.lang.Stringvaluedefault_db/value/argument/bean/blueprint 请注意样板配置由处理程序类型和事件总线地址组成。 其他配置主机端口和数据库名称特定于MongoDB持久程序。 这是模块化的MongoDB busmod代码 public class MongoPersistor extends BusModBaseimplements HandlerMessageJsonObject {private final String host;private final int port;private final String dbName;private final Mongo mongo;private final DB db;public MongoPersistor(String host, int port, String dbName)throws UnknownHostException, MongoException {this.host host;this.port port;this.dbName dbName;this.mongo new Mongo(host, port);this.db this.mongo.getDB(dbName);}public void stop() {mongo.close();}public void handle(MessageJsonObject message) {...}} 该代码仍然扩展了BusModBase仅仅是因为BusModBase提供了几种方便的辅助方法。 同样与非模块化等效代码相比生成的代码更简单更易于单元测试。 模块化事件总线客户端 最后我需要一个模块化的Verticle来测试模块化的MongoDB持久性。 这些verticle需要做的就是将适当的消息发布到事件总线。 普通的vert.x垂直版本使用Vertx类获取事件总线但是我再次使用了Blueprint服务这次是在服务注册表中查找事件总线服务并将其注入到模块化垂直版本中。 我还扩展了org.vertx.osgi捆绑包以便在服务注册表中发布事件总线服务。 模块化事件总线客户端的blueprint.xml如下 ?xml version1.0 encodingUTF-8?
blueprint xmlnshttp://www.osgi.org/xmlns/blueprint/v1.0.0reference ideventBus interfaceorg.vertx.java.core.eventbus.EventBus/bean classorg.vertx.osgi.sample.mongo.MongoClientargument refeventBus/argument typejava.lang.Stringvaluevertx.mongopersistor/value/argument/bean/blueprint 然后 模块化事件总线客户端代码非常简单 public final class MongoClient {public MongoClient(EventBus eventBus, String address) {JsonObject msg ...eventBus.send(address, msg,new HandlerMessageJsonObject(){...});}} 旋转一下 1.我已经在git的bundles目录中提供了所有必需的OSGi捆绑包 。 您可以通过克隆git存储库来获取它们 git clone git://github.com/glyn/vert.x.osgi.git 或通过下载git repo的zip文件 。 2. vert.x需要Java 7 因此请设置一个终端外壳以使用Java7 。确保正确设置了JAVA_HOME环境变量。 如果现在无法获取Java 7则将捆绑软件部署到OSGi时会看到一些错误并且您将无法在步骤8和9中运行示例。 3.如果您是OSGi用户只需在您喜欢的OSGi框架或容器中安装并启动捆绑软件然后跳至步骤8。否则请按以下方式使用git存储库中的Virgo内核副本。 4.将目录更改为git repo的本地副本中的virgo-kernel-…目录。 5.在UNIX上发出 bin/startup.sh -clean 或在Windows上发出 bin\startup.bat -clean 6.处女座内核应启动并在其拾取目录中部署各种捆绑软件 org.vertx.osgi捆绑包 org.vertx.osgi-0.0.1.jar HTTP示例模块化org.vertx.osgi.sample.basic-1.0.0.jar org.vertx.osgi.sample.basic-1.0.0.jar SockJS示例模块化verticle org.vertx.osgi.sample.sockjs-1.0.0.jar MongoDB持久性示例模块化busmod org.vertx.osgi.mods.mongo-1.0.0.jar 7.如果要查看现在正在运行的捆绑软件请从另一个终端启动Virgo Shell telnet localhost 2501 并使用ss或lb命令汇总已安装的捆绑软件。 help命令将列出其他可用命令而disconnect将使您脱离Virgo Shell。 这是ss命令的典型输出 ...
89 ACTIVE org.vertx.osgi_0.0.1
90 ACTIVE jackson-core-asl_1.9.4
91 ACTIVE jackson-mapper-asl_1.9.4
92 ACTIVE org.jboss.netty_3.4.2.Final
93 ACTIVE org.vertx.core_1.0.0.final
94 ACTIVE org.vertx.osgi.mods.mongo_1.0.0
95 ACTIVE com.mongodb_2.7.2
96 ACTIVE org.vertx.platform_1.0.0.final
97 ACTIVE org.vertx.osgi.sample.basic_1.0.0
98 ACTIVE org.vertx.osgi.sample.sockjs_1.0.0 和lb命令包括更具描述性的Bundle-Name标头 ...89|Active | 4|vert.x OSGi Integration (0.0.1)90|Active | 4|Jackson JSON processor (1.9.4)91|Active | 4|Data mapper for Jackson JSON processor (1.9.4)92|Active | 4|The Netty Project (3.4.2.Final)93|Active | 4|vert.x Core (1.0.0.final)94|Active | 4|MongoDB BusMod (1.0.0)95|Active | 4|MongoDB (2.7.2)96|Active | 4|vert.x Platform (1.0.0.final)97|Active | 4|Sample Basic HTTP Verticle (1.0.0)98|Active | 4|Sample SockJS Verticle (1.0.0) 8.现在您可以使用Web浏览器在localhost8090尝试基本的HTTP示例该示例应响应“ hello”或在http// localhost8091的SockJS示例应显示一个框您可以在其中输入一些文本和一个按钮单击该按钮会弹出一个窗口 9.如果要尝试无头的MongoDB事件总线客户端请下载MondoDB并在其默认端口上本地启动 然后将org.vertx.osgi.sample.mongo-1.0.0.jar从bundles目录复制到Virgo的提取目录。 此捆绑包启动后它将立即向事件总线发送一条消息并驱动MongoDB持久程序更新数据库。 如果您不想使用MongoDB来检查是否已进行了更新请查看处女座的日志在serviceability/logs/log.log 以查看一些System.out行如下所示该行确认了发生的情况 System.out Sending message: {actionsave, document{xy}, collectionvertx.osgi}
...
System.out Message sent
...
System.out Message response {_id95..., statusok} OSGi和vert.x模块化 在本案例研究中各种示例OSGi捆绑包都依赖于并共享vert.x核心捆绑包。 每个捆绑包都加载在其自己的类加载器中并且OSGi根据OSGi捆绑包的连接方式控制类加载和资源查找的委派。 以相同的方式写为OSGi包的顶点可以自由地依赖和共享其他OSGi包。 这与vert.x模块系统大不相同在vert.x模块系统中一个verticle依赖的任何模块除了busmod之外都被加载到与verticle相同的类加载器中。 OSGi模块系统的优点在于每个模块的单个副本安装在系统中并且对于诸如Virgo shell之类的工具可见并且可以由其管理。 它还使占地面积最小。 vert.x模块系统的优点是在各个顶点之间不存在模块共享因此编写不当的模块不会无意或有意地泄漏独立顶点之间的信息。 另外每个使用它的垂直模块都有每个非busmod模块的单独副本因此可以编写模块而不必担心线程安全因为每个副本仅在其垂直线程上执行。 但是OSGi用户可能很高兴要求可重用的模块具有线程安全性并谨慎地管理任何可变的静态数据以避免线程之间的泄漏。 更换容器 当我提出将vert.x嵌入OSGi的话题时 vert.x的负责人蒂姆·福克斯Tim Fox问我是否正在编写当前容器的替代品对此我回答“不是真的”。 我之所以这么说是因为我喜欢vert.x的事件驱动编程模型及其线程模型它们似乎是“容器”的一部分。 但我想更换一对夫妇的vert.x容器方面模块系统和verticles登记处理的方式。 后来让我吃惊的是“容器”作为整体实体的概念在模块化系统中可能有点奇怪最好考虑多个单独的容器概念然后可以采用不同的方式组合以适应不同的容器用户。 但是上面看到的类加载和线程模型之间的微妙相互作用表明包含的不同概念可以相互依赖。 我想知道其他人如何看待“容器”的概念吗 结论 由于OSGi框架是一个相当严格的应用程序因此vert.x声称它可以嵌入其他应用程序中的说法已得到验证。 vert.x模块系统虽然未在模块之间提供隔离但确实在应用程序之间包括顶点及其模块提供了隔离并且使模块的编写无需关注线程安全性。 提出了一个vert.x问题2 这应该使vert.x更易于使用自定义类加载器嵌入其他环境。 vert.x可以遵循nettyjackson和MongoDB JAR的示例并在其核心JAR和平台JAR中包含OSGi清单以避免OSGi用户不得不将这些JAR转换为OSGi捆绑软件。 我将这个问题留给其他人提出因为我无法评估在OSGi中使用vert.x的需求。 在OSGi中运行vert.x可以满足一些出色的vert.x要求例如如何自动化容器内测试OSGi有许多解决方案包括Pax Exam而Virgo有集成测试框架以及如何开发verticles并将它们部署到vert .x在IDE的控制下请参阅Virgo IDE工具指南 。 处女座还提供了许多附带的好处包括用于检查和管理束和顶点的管理外壳复杂的诊断程序以及更多其他功能有关详细信息请参阅处女座白皮书 。 该练习还为处女座带来了一些不错的收益。 修复了370253错误 这是在Java 7下运行Virgo的唯一已知问题。Virgo3.5依赖于在此环境中中断的Gemini蓝图因此引发并修复了错误379384 。 我使用了新的基于Eclipse的Virgo工具来开发各种捆绑软件并在Virgo中运行它们。 结果我在工具中发现了一些小问题这些问题将适时解决。 最后在Virgo内核上运行vert.x进一步验证了该内核适合构建自定义服务器运行时因为现在除了TomcatJetty以及在内核上运行的一两个自定义服务器之外我们还拥有vert.x。 脚注 在IBM的日子里我曾在CICS开发团队工作过。 SpringSource的一位同事给了我“ CICS做到了” 我们开始合作后不久就穿了T恤。 旧习难改。 模块化垂直模块当前需要拦截vert.x的资源查找逻辑以便可以轻松提供捆绑中的文件。 将此通用代码移至org.vertx.osgi捆绑包会更好但这需要首先实现vert.x问题161 。 参考 OSGi案例研究来自Mind the Gap博客的JCG合作伙伴 Glyn Normington 的模块化vert.x。 翻译自: https://www.javacodegeeks.com/2012/07/osgi-case-study-modular-vertx.htmlosgi 模块化
