osgi 模塊化

OSGi使Java代碼可以清晰地劃分為多個(gè)模塊，這些模塊稱為捆綁軟件 ，可以訪問由每個(gè)捆綁軟件的類加載器控制的代碼和資源。 OSGi 服務(wù)提供了一種附加的分離機(jī)制：接口的用戶無需依賴于實(shí)現(xiàn)類，工廠等。

以下案例研究旨在使OSGi捆綁包和服務(wù)的上述優(yōu)勢(shì)具體化。 它采用了一個(gè)有趣的Java項(xiàng)目vert.x，并展示了如何將其嵌入OSGi并利用OSGi的功能。

免責(zé)聲明：我不建議更換vert.x容器或其模塊系統(tǒng)。 這主要是在OSGi的使用中進(jìn)行的案例研究，盡管某些發(fā)現(xiàn)應(yīng)促使對(duì)vert.x進(jìn)行改進(jìn)，尤其是將其嵌入具有自定義類加載器的應(yīng)用程序中時(shí)。

版本號(hào)

vert.x開源項(xiàng)目提供了node.js的JVM替代方案：異步，事件驅(qū)動(dòng)的編程模型，用于以多種語言（包括Java，Groovy，JavaScript和Ruby）編寫Web應(yīng)用程序。

vert.x支持HTTP以及現(xiàn)代協(xié)議，例如WebSockets和sockjs （與WebSockets 相比 ，它們?cè)诟嗟臑g覽器中工作，并且可以更輕松地穿越防火墻）。
vert.x具有分布式事件總線，允許已知為verticles并稱為busmods共享代碼庫vert.x應(yīng)用程序之間進(jìn)行傳播JSON消息。 busmod是一種特殊的Verticle，它處理事件總線中的事件。 vert.x附帶了一些busmod，例如MongoDB的 “ persistor”，用戶可以編寫自己的。

vert.x的線程模型很有趣，因?yàn)槊總€(gè)頂點(diǎn)（或busmod）在其生命周期內(nèi)都綁定到特定線程，因此，頂點(diǎn)代碼無需關(guān)注線程安全性。 線程池用于在頂點(diǎn)上分派工作，并且每個(gè)頂點(diǎn)必須避免阻塞或長時(shí)間運(yùn)行的操作，以免影響服務(wù)器吞吐量（vert.x提供了有效地實(shí)現(xiàn)長時(shí)間運(yùn)行的操作的單獨(dú)機(jī)制）。 這類似于CICS事務(wù)處理器中的準(zhǔn)可重入線程模型。 ^1個(gè)

這里特別受關(guān)注的是vert.x模塊系統(tǒng)，該系統(tǒng)每個(gè)頂點(diǎn)都有一個(gè)類加載器，還有稱為模塊的代碼庫，它們被加載到使用它們的每個(gè)頂點(diǎn)的類加載器中。 因此，除了通過事件總線之外，沒有其他方法可以在各個(gè)頂點(diǎn)之間共享代碼。

vert.x具有出色的文檔，包括主要手冊(cè) ， java手冊(cè) （以及其他語言的手冊(cè)）， 教程和可運(yùn)行的代碼示例 。

OSGi

如果您還不熟悉OSGi，請(qǐng)閱讀我的OSGi簡介帖子，但是現(xiàn)在不要再理會(huì)該帖子中的鏈接-您可以隨時(shí)返回并稍后再做。

在OSGi中嵌入vert.x

我通過幾個(gè)小步驟來完成此操作，下面依次介紹了這些步驟：將vert.x JAR轉(zhuǎn)換為OSGi捆綁包，然后模塊化verticle，busmod和事件總線客戶端。

將vert.x JAR轉(zhuǎn)換為OSGi捆綁軟件

vert.x手冊(cè)鼓勵(lì)用戶使用vert.x核心JAR將vert.x嵌入自己的應(yīng)用程序中，因此將vert.x嵌入OSGi的第一步是將vert.x核心JAR轉(zhuǎn)換為OSGi捆綁包，因此可以將其加載到OSGi運(yùn)行時(shí)中。

我使用了Bundlor工具，盡管其他工具（例如bnd）也可以很好地工作。 Bundlor接受一個(gè)模板，然后分析JAR的字節(jié)碼以產(chǎn)生帶有適當(dāng)OSGi清單標(biāo)頭的新JAR。 請(qǐng)立即參閱SpringSource Bundlor文檔以獲取有關(guān)Bundlor的更多信息，因?yàn)樵谧珜懕疚臅r(shí)Eclipse Virgo Bundlor文檔尚未發(fā)布，即使Bundlor項(xiàng)目已轉(zhuǎn)移到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;version=0,org.codehaus.groovy.*;resolution:=optional;version=0,javax.net.ssl;resolution:=optional;version=0,org.apache.log4j;resolution:=optional;version=0,org.slf4j;resolution:=optional;version=0 Export-Template: *;version="1.0.0.final"

（此案例研究的模板和所有其他部分都可以在github上找到 。）

這是為JAR依賴的軟件包定義有效的版本范圍（范圍“ 0”表示0或更大的版本范圍），這些軟件包是可選的還是強(qiáng)制的，以及JAR自己的軟件包應(yīng)為哪個(gè)版本出口處。 它還為捆綁軟件提供了符號(hào)名稱 （用于標(biāo)識(shí)捆綁軟件），版本和（描述性）名稱。 有了這些信息，OSGi然后通過委派包類加載器之間的類加載和資源查找，將包的依賴關(guān)系連接在一起。

值得慶幸的網(wǎng)狀網(wǎng)絡(luò)JAR和杰克遜 JSON JAR文件將vert.x核心JAR取決于附帶有效的OSGi清單。

為了驗(yàn)證清單是否有效，我嘗試在處女座內(nèi)核中部署vert.x核心軟件包。 只需將vert.x核心軟件包放置在拾取目錄中，并將其依賴項(xiàng)放置在repository / usr目錄中，然后啟動(dòng)內(nèi)核即可。 以下控制臺(tái)消息顯示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; version="1.0.0.final"[exported]org.vertx.java.core.buffer; version="1.0.0.final"[exported]...Imported packagesorg.jboss.netty.util; version="3.4.2.Final"<org.jboss.netty_3.4.2.final [92]>...org.codehaus.jackson.map; version="1.9.4"<jackson-mapper-asl_1.9.4 [91]>...

我還按照以后需要的類似方式將vert.x平臺(tái)JAR轉(zhuǎn)換為OSGi捆綁軟件。

模塊化頂點(diǎn)

一個(gè)典型的頂點(diǎn)如下所示：

public class ServerExample extends Verticle {public void start() {vertx.createHttpServer().requestHandler(new Handler<httpserverrequest>() {public void handle(HttpServerRequest req) {...}}).listen(8080);} }

調(diào)用start方法時(shí)，它將創(chuàng)建一個(gè)HTTP服務(wù)器，并向該服務(wù)器注冊(cè)一個(gè)處理程序，并設(shè)置服務(wù)器在端口上偵聽。 除了處理程序的主體之外，該代碼的其余部分都是樣板。 因此，我決定將樣板分解為一個(gè)通用的OSGi捆綁包（org.vertx.osgi），并用包含處理程序和一些等同于樣板的聲明性元數(shù)據(jù)的模塊化頂包來替換該豎版。 常見的OSGi捆綁包使用白板模式來偵聽OSGi服務(wù)注冊(cè)表中的特定種類的服務(wù)，基于元數(shù)據(jù)創(chuàng)建樣板，并向生成的HTTP服務(wù)器注冊(cè)處理程序。

讓我們看一下模塊化的vertical bundle。 它的代碼包含一個(gè)HttpServerRequestHandler類： ²

public final class HttpServerRequestHandler implements Handler<httpserverrequest> {public void handle(HttpServerRequest req) {...}}

它還具有服務(wù)屬性形式的聲明性元數(shù)據(jù)，這些聲明元數(shù)據(jù)與處理程序一起在OSGi服務(wù)注冊(cè)表中注冊(cè)。 我可以使用OSGi藍(lán)圖服務(wù)來執(zhí)行此操作，盡管我可以使用OSGi聲明性服務(wù)，甚至可以使用OSGi API以編程方式注冊(cè)該服務(wù)。 藍(lán)圖元數(shù)據(jù)是捆綁軟件中的文件blueprint.xml ，如下所示：

<?xml version="1.0" encoding="UTF-8"?> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"><service interface="org.vertx.java.core.Handler" ref="handler"><service-properties><entry key="type" value="HttpServerRequestHandler"><entry key="port" value="8090"></service-properties></service><bean class="org.vertx.osgi.sample.basic.HttpServerRequestHandler"id="handler"/></blueprint>

此元數(shù)據(jù)聲明應(yīng)創(chuàng)建HTTP服務(wù)器（通過類型服務(wù)屬性），向其注冊(cè)的處理程序以及偵聽端口8090的服務(wù)器集（通過端口服務(wù)屬性）。 當(dāng)org.vertx.osgi捆綁包運(yùn)行時(shí)，這一切都是通過白板模式完成的，如下所示。

請(qǐng)注意，模塊化Verticle僅依賴于Handler和HttpServerRequest類，而原始Verticle也依賴于Vertx，HttpServer和Verticle類。 對(duì)于那些喜歡單元測(cè)試（除了容器內(nèi)測(cè)試）的人來說，這也使事情變得簡單得多，因?yàn)樾枰哪M或存根數(shù)量更少。

那么我們現(xiàn)在有什么呢？ 將兩個(gè)包添加到我們之前安裝的包中：一個(gè)org.vertx.osgi包，它封裝了樣板代碼；一個(gè)應(yīng)用程序包，它代表一個(gè)模塊化的verticle。 我們還需要一個(gè)Blueprint服務(wù)實(shí)現(xiàn)-從Virgo 3.5開始，Virgo內(nèi)核內(nèi)置了一個(gè)Blueprint實(shí)現(xiàn)。 以下交互圖顯示了一種可能的事件序列：

在OSGi中，每個(gè)捆綁包都有其自己的生命周期，并且通常設(shè)計(jì)捆綁包時(shí)，無論它們相對(duì)于其他捆綁包啟動(dòng)的順序如何，它們都將正確運(yùn)行。 在上面的示例中，假定的啟動(dòng)順序?yàn)?#xff1a;藍(lán)圖服務(wù)，org.vertx.osgi包，模塊化verticle包。 但是，org.vertx.osgi捆綁包可以在模塊化Verticle捆綁包之后開始，并且最終結(jié)果將是相同的：將創(chuàng)建服務(wù)器，并且在服務(wù)器上注冊(cè)模塊化Verticle捆綁包的處理程序，并且服務(wù)器設(shè)置監(jiān)聽。 如果藍(lán)圖服務(wù)是在org.vertx.osgi和模塊化Verticle捆綁包之后啟動(dòng)的，那么直到藍(lán)圖服務(wù)啟動(dòng)后，org.vertx.osgi捆綁包才會(huì)檢測(cè)到該模塊化Verticle捆綁包的處理程序服務(wù)出現(xiàn)在服務(wù)注冊(cè)表中，但是最終結(jié)果將再次相同。

github項(xiàng)目包含一些示例模塊化verticle的源代碼： 基本的HTTP垂直版本 （在8090端口上運(yùn)行）和sockjs verticle （在8091端口上運(yùn)行）。 org.vertx.osgi捆綁軟件需要更多代碼來支持sockjs，而模塊化的sockjs verticle除了提供HTTP處理程序外，還需要提供sockjs處理程序。

模塊化BusMods

MongoDB持久程序是處理來自事件總線的消息的busmod的典型示例：

public class MongoPersistor extends BusModBase implements Handler<message<jsonobject>> {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(Message<jsonobject> message) {...}}

同樣，這里混合了樣板代碼（用于注冊(cè)事件總線處理程序），啟動(dòng)/停止邏輯，配置處理以及事件總線處理程序本身。 我對(duì)其他版本應(yīng)用了類似的方法，并將樣板代碼分離到org.vertx.osgi包中，將處理程序和元數(shù)據(jù)（包括配置）保留在模塊化busmod中。 持久性對(duì)MongoDB客戶端JAR（mongo.jar）的依賴很方便，因?yàn)榇薐AR附帶了有效的OSGi清單。

這是blueprint.xml ：

<?xml version="1.0" encoding="UTF-8"?> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"><service ref="handler" interface="org.vertx.java.core.Handler"><service-properties><entry key="type" value="EventBusHandler"/><entry key="address" value="vertx.mongopersistor"/></service-properties></service><bean id="handler" class="org.vertx.osgi.mod.mongo.MongoPersistor"destroy-method="stop"><argument type="java.lang.String"><value>localhost</value></argument><argument type="int"><value>27017</value></argument><argument type="java.lang.String"><value>default_db</value></argument></bean></blueprint>

請(qǐng)注意，樣板配置由處理程序類型和事件總線地址組成。 其他配置（主機(jī)，端口和數(shù)據(jù)庫名稱）特定于MongoDB持久程序。

這是模塊化的MongoDB busmod代碼 ：

public class MongoPersistor extends BusModBaseimplements Handler<Message<JsonObject>> {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(Message<JsonObject> message) {...}}

該代碼仍然擴(kuò)展了BusModBase，僅僅是因?yàn)锽usModBase提供了幾種方便的輔助方法。 同樣，與非模塊化等效代碼相比，生成的代碼更簡單，更易于單元測(cè)試。

模塊化事件總線客戶端

最后，我需要一個(gè)模塊化的Verticle來測(cè)試模塊化的MongoDB持久性。 這些verticle需要做的就是將適當(dāng)?shù)南l(fā)布到事件總線。 普通的vert.x垂直版本使用Vertx類獲取事件總線，但是我再次使用了Blueprint服務(wù)，這次是在服務(wù)注冊(cè)表中查找事件總線服務(wù)，并將其注入到模塊化垂直版本中。 我還擴(kuò)展了org.vertx.osgi捆綁包，以便在服務(wù)注冊(cè)表中發(fā)布事件總線服務(wù)。

模塊化事件總線客戶端的blueprint.xml如下：

<?xml version="1.0" encoding="UTF-8"?> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"><reference id="eventBus" interface="org.vertx.java.core.eventbus.EventBus"/><bean class="org.vertx.osgi.sample.mongo.MongoClient"><argument ref="eventBus"/><argument type="java.lang.String"><value>vertx.mongopersistor</value></argument></bean></blueprint>

然后， 模塊化事件總線客戶端代碼非常簡單：

public final class MongoClient {public MongoClient(EventBus eventBus, String address) {JsonObject msg = ...eventBus.send(address, msg,new Handler<Message<JsonObject>>(){...});}}

旋轉(zhuǎn)一下

1.我已經(jīng)在git的bundles目錄中提供了所有必需的OSGi捆綁包 。 您可以通過克隆git存儲(chǔ)庫來獲取它們：

git clone git://github.com/glyn/vert.x.osgi.git

或通過下載git repo的zip文件 。

2. vert.x需要Java 7 ，因此請(qǐng)?jiān)O(shè)置一個(gè)終端外殼以使用Java7 。確保正確設(shè)置了JAVA_HOME環(huán)境變量。 （如果現(xiàn)在無法獲取Java 7，則將捆綁軟件部署到OSGi時(shí)會(huì)看到一些錯(cuò)誤，并且您將無法在步驟8和9中運(yùn)行示例。）

3.如果您是OSGi用戶，只需在您喜歡的OSGi框架或容器中安裝并啟動(dòng)捆綁軟件，然后跳至步驟8。否則，請(qǐng)按以下方式使用git存儲(chǔ)庫中的Virgo內(nèi)核副本。

4.將目錄更改為git repo的本地副本中的virgo-kernel-…目錄。

5.在UNIX上，發(fā)出：

bin/startup.sh -clean

或在Windows上，發(fā)出：

bin\startup.bat -clean

6.處女座內(nèi)核應(yīng)啟動(dòng)并在其拾取目錄中部署各種捆綁軟件：

• 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.如果要查看現(xiàn)在正在運(yùn)行的捆綁軟件，請(qǐng)從另一個(gè)終端啟動(dòng)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標(biāo)頭）：

...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.現(xiàn)在，您可以使用Web瀏覽器在localhost：8090嘗試基本的HTTP示例，該示例應(yīng)響應(yīng)“ hello”，或在http：// localhost：8091的SockJS示例應(yīng)顯示一個(gè)框，您可以在其中輸入一些文本和一個(gè)按鈕，單擊該按鈕會(huì)彈出一個(gè)窗口：

9.如果要嘗試（無頭的）MongoDB事件總線客戶端，請(qǐng)下載MondoDB并在其默認(rèn)端口上本地啟動(dòng) ，然后將org.vertx.osgi.sample.mongo-1.0.0.jar從bundles目錄復(fù)制到Virgo的提取目錄。 此捆綁包啟動(dòng)后，它將立即向事件總線發(fā)送一條消息，并驅(qū)動(dòng)MongoDB持久程序更新數(shù)據(jù)庫。 如果您不想使用MongoDB來檢查是否已進(jìn)行了更新，請(qǐng)查看處女座的日志（在serviceability/logs/log.log ）以查看一些System.out行，如下所示，該行確認(rèn)了發(fā)生的情況：

System.out Sending message: {action=save, document={x=y}, collection=vertx.osgi} ... System.out Message sent ... System.out Message response {_id=95..., status=ok}

OSGi和vert.x模塊化

在本案例研究中，各種示例OSGi捆綁包都依賴于并共享vert.x核心捆綁包。 每個(gè)捆綁包都加載在其自己的類加載器中，并且OSGi根據(jù)OSGi捆綁包的連接方式控制類加載和資源查找的委派。 以相同的方式，寫為OSGi包的頂點(diǎn)可以自由地依賴和共享其他OSGi包。

這與vert.x模塊系統(tǒng)大不相同，在vert.x模塊系統(tǒng)中，一個(gè)verticle依賴的任何模塊（除了busmod之外）都被加載到與verticle相同的類加載器中。

OSGi模塊系統(tǒng)的優(yōu)點(diǎn)在于，每個(gè)模塊的單個(gè)副本安裝在系統(tǒng)中，并且對(duì)于諸如Virgo shell之類的工具可見并且可以由其管理。 它還使占地面積最小。

vert.x模塊系統(tǒng)的優(yōu)點(diǎn)是，在各個(gè)頂點(diǎn)之間不存在模塊共享，因此編寫不當(dāng)?shù)哪K不會(huì)無意或有意地泄漏獨(dú)立頂點(diǎn)之間的信息。 另外，每個(gè)使用它的垂直模塊都有每個(gè)（非busmod）模塊的單獨(dú)副本，因此可以編寫模塊而不必?fù)?dān)心線程安全，因?yàn)槊總€(gè)副本僅在其垂直線程上執(zhí)行。 但是，OSGi用戶可能很高興要求可重用的模塊具有線程安全性，并謹(jǐn)慎地管理任何可變的靜態(tài)數(shù)據(jù)，以避免線程之間的泄漏。 ?

更換容器？

當(dāng)我提出將vert.x嵌入OSGi的話題時(shí)， vert.x的負(fù)責(zé)人蒂姆·福克斯（Tim Fox）問我是否正在編寫當(dāng)前容器的替代品，對(duì)此我回答“不是真的”。 我之所以這么說是因?yàn)槲蚁矚gvert.x的事件驅(qū)動(dòng)編程模型及其線程模型，它們似乎是“容器”的一部分。 但我想更換一對(duì)夫婦的vert.x容器方面：模塊系統(tǒng)和verticles登記處理的方式。

后來讓我吃驚的是，“容器”作為整體實(shí)體的概念在模塊化系統(tǒng)中可能有點(diǎn)奇怪，最好考慮多個(gè)單獨(dú)的容器概念，然后可以采用不同的方式組合以適應(yīng)不同的容器用戶。 但是，上面看到的類加載和線程模型之間的微妙相互作用表明，包含的不同概念可以相互依賴。 我想知道其他人如何看待“容器”的概念嗎？

結(jié)論

由于OSGi框架是一個(gè)相當(dāng)嚴(yán)格的應(yīng)用程序，因此vert.x聲稱它可以嵌入其他應(yīng)用程序中的說法已得到驗(yàn)證。

vert.x模塊系統(tǒng)雖然未在模塊之間提供隔離，但確實(shí)在應(yīng)用程序之間（包括頂點(diǎn)及其模塊）提供了隔離，并且使模塊的編寫無需關(guān)注線程安全性。

提出了一個(gè)vert.x問題² ，這應(yīng)該使vert.x更易于使用自定義類加載器嵌入其他環(huán)境。

vert.x可以遵循netty，jackson和MongoDB JAR的示例，并在其核心JAR和平臺(tái)JAR中包含OSGi清單，以避免OSGi用戶不得不將這些JAR轉(zhuǎn)換為OSGi捆綁軟件。 我將這個(gè)問題留給其他人提出，因?yàn)槲覠o法評(píng)估在OSGi中使用vert.x的需求。

在OSGi中運(yùn)行vert.x可以滿足一些出色的vert.x要求，例如如何自動(dòng)化容器內(nèi)測(cè)試（OSGi有許多解決方案，包括Pax Exam，而Virgo有集成測(cè)試框架）以及如何開發(fā)verticles并將它們部署到vert .x在IDE的控制下（請(qǐng)參閱Virgo IDE工具指南 ）。 處女座還提供了許多附帶的好處，包括用于檢查和管理束和頂點(diǎn)的管理外殼，復(fù)雜的診斷程序以及更多其他功能（有關(guān)詳細(xì)信息，請(qǐng)參閱處女座白皮書 ）。

該練習(xí)還為處女座帶來了一些不錯(cuò)的收益。 修復(fù)了370253錯(cuò)誤 ，這是在Java 7下運(yùn)行Virgo的唯一已知問題。Virgo3.5依賴于在此環(huán)境中中斷的Gemini藍(lán)圖，因此引發(fā)并修復(fù)了錯(cuò)誤379384 。 我使用了新的基于Eclipse的Virgo工具來開發(fā)各種捆綁軟件并在Virgo中運(yùn)行它們。 結(jié)果，我在工具中發(fā)現(xiàn)了一些小問題，這些問題將適時(shí)解決。

最后，在Virgo內(nèi)核上運(yùn)行vert.x進(jìn)一步驗(yàn)證了該內(nèi)核適合構(gòu)建自定義服務(wù)器運(yùn)行時(shí)，因?yàn)楝F(xiàn)在除了Tomcat，Jetty以及在內(nèi)核上運(yùn)行的一兩個(gè)自定義服務(wù)器之外，我們還擁有vert.x。

腳注：

在IBM的日子里，我曾在CICS開發(fā)團(tuán)隊(duì)工作過。 SpringSource的一位同事給了我“ CICS做到了！” 我們開始合作后不久就穿了T恤。 舊習(xí)難改。

模塊化垂直模塊當(dāng)前需要攔截vert.x的資源查找邏輯，以便可以輕松提供捆綁中的文件。 將此通用代碼移至org.vertx.osgi捆綁包會(huì)更好，但這需要首先實(shí)現(xiàn)vert.x問題161 。

參考： OSGi案例研究：來自Mind the Gap博客的JCG合作伙伴 Glyn Normington 的模塊化vert.x。

翻譯自: https://www.javacodegeeks.com/2012/07/osgi-case-study-modular-vertx.html

osgi 模塊化

總結(jié)

以上是生活随笔為你收集整理的osgi 模块化_OSGi案例研究：模块化vert.x的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。