OSGi案例研究：模块化vert.x
以下案例研究旨在使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開(kāi)源項(xiàng)目提供了node.js的JVM替代方案：異步，事件驅(qū)動(dòng)的編程模型，用于以多種語(yǔ)言（包括Java，Groovy，JavaScript和Ruby）編寫Web應(yīng)用程序。
vert.x支持HTTP以及現(xiàn)代協(xié)議，例如WebSockets和sockjs （與WebSockets 相比 ，它們?cè)诟嗟臑g覽器中工作，并且可以更輕松地穿越防火墻）。
vert.x具有分布式事件總線，允許已知為verticles并稱為busmods共享代碼庫(kù)vert.x應(yīng)用程序之間進(jìn)行傳播JSON消息。 busmod是一種特殊的Verticle，它處理事件總線中的事件。 vert.x艦艇一些busmods，如MongoDB的 “persistor”，用戶可以寫自己的。
vert.x的線程模型很有趣，因?yàn)槊總€(gè)頂點(diǎn)（或busmod）在其生命周期內(nèi)都綁定到特定線程，因此，頂點(diǎn)代碼無(wú)需關(guān)注線程安全性。 線程池用于在頂點(diǎn)上分派工作，并且每個(gè)頂點(diǎn)必須避免阻塞或長(zhǎng)時(shí)間運(yùn)行的操作，以免影響服務(wù)器吞吐量（vert.x提供了有效地實(shí)現(xiàn)長(zhǎng)時(shí)間運(yùn)行的操作的單獨(dú)機(jī)制）。 這類似于CICS事務(wù)處理器中的準(zhǔn)可重入線程模型。 1個(gè)
這里特別受關(guān)注的是vert.x模塊系統(tǒng)，該系統(tǒng)在每個(gè)頂點(diǎn)上都有一個(gè)類加載器和稱為模塊的代碼庫(kù)，它們被加載到使用它們的每個(gè)頂點(diǎn)的類加載器中。 因此，除了通過(guò)事件總線之外，沒(méi)有其他方法可以在各個(gè)頂點(diǎn)之間共享代碼。
vert.x具有出色的文檔，包括主要手冊(cè) ， java手冊(cè) （以及其他語(yǔ)言的手冊(cè)）， 教程和可運(yùn)行的代碼示例 。
OSGi
如果您還不熟悉OSGi，請(qǐng)閱讀我的OSGi簡(jiǎn)介文章，但現(xiàn)在不要再理會(huì)該文章中的鏈接-您可以隨時(shí)返回并稍后再做。
將vert.x嵌入OSGi
我通過(guò)幾個(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é)碼以生成帶有適當(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ò)委派包類加載器之間的類加載和資源查找，將包的依賴關(guān)系連接在一起。
值得慶幸的網(wǎng)狀網(wǎng)絡(luò)JAR和杰克遜 JSON JAR文件將vert.x核心JAR取決于附帶有效的OSGi清單。
為了驗(yàn)證清單是否有效，我嘗試在處女座內(nèi)核中部署vert.x核心軟件包。 只需將vert.x核心捆綁包放置在Pickup目錄中，并將其依賴項(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ù)器在端口上偵聽(tīng)。 除了處理程序的主體之外，該代碼的其余部分都是樣板。 因此，我決定將樣板分解為一個(gè)通用的OSGi捆綁包（org.vertx.osgi），并用包含處理程序和一些等同于樣板的聲明性元數(shù)據(jù)的模塊化頂包替換該頂標(biāo)。 常見(jiàn)的OSGi捆綁包使用白板模式來(lái)偵聽(tīng)OSGi服務(wù)注冊(cè)表中的特定種類的服務(wù)，基于元數(shù)據(jù)創(chuàng)建樣板，并向生成的HTTP服務(wù)器注冊(cè)處理程序。
讓我們看一下模塊化的vertical bundle。 它的代碼包含一個(gè)HttpServerRequestHandler類： 2
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ù)來(lái)執(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ù)器（通過(guò)類型服務(wù)屬性），向其注冊(cè)的處理程序以及偵聽(tīng)端口8090的服務(wù)器集（通過(guò)端口服務(wù)屬性）。 當(dāng)org.vertx.osgi捆綁包運(yùn)行時(shí)，這一切都是通過(guò)白板模式完成的，如下所示。
請(qǐng)注意，模塊化Verticle僅依賴于Handler和HttpServerRequest類，而原始Verticle也依賴于Vertx，HttpServer和Verticle類。 對(duì)于那些喜歡單元測(cè)試（除了容器內(nèi)測(cè)試）的人來(lái)說(shuō)，這也使事情變得簡(jiǎn)單得多，因?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開(kāi)始，Virgo內(nèi)核內(nèi)置了一個(gè)Blueprint實(shí)現(xiàn)。 以下交互圖顯示了一種可能的事件序列：
在OSGi中，每個(gè)捆綁軟件都有其自己的生命周期，并且通常設(shè)計(jì)捆綁軟件時(shí)，無(wú)論它們相對(duì)于其他捆綁軟件啟動(dòng)的順序如何，它們都將正確運(yùn)行。 在上面的示例中，假定的開(kāi)始順序?yàn)?#xff1a;藍(lán)圖服務(wù)，org.vertx.osgi包，模塊化verticle包。 但是，org.vertx.osgi捆綁包可以在模塊化Verticle捆綁包之后開(kāi)始，并且最終結(jié)果將是相同的：將創(chuàng)建服務(wù)器，并且在服務(wù)器上注冊(cè)模塊化Verticle捆綁包的處理程序，并且服務(wù)器設(shè)置監(jiān)聽(tīng)。 如果藍(lán)圖服務(wù)是在org.vertx.osgi和模塊化Verticle捆綁包之后啟動(dòng)的，那么直到藍(lán)圖服務(wù)啟動(dòng)后，org.vertx.osgi捆綁包才會(huì)檢測(cè)到模塊化注冊(cè)表包的處理程序服務(wù)出現(xiàn)在服務(wù)注冊(cè)表中，但是最終結(jié)果將再次相同。
github項(xiàng)目包含一些示例模塊verticle的源代碼： 基本的HTTP垂直版本 （在8090端口上運(yùn)行）和sockjs verticle （在8091端口上運(yùn)行）。 org.vertx.osgi捆綁軟件需要更多的代碼來(lái)支持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ù)庫(kù)名稱）特定于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提供了幾種方便的輔助方法。 同樣，與非模塊化等效代碼相比，生成的代碼更簡(jiǎn)單，更易于單元測(cè)試。
模塊化事件總線客戶端
最后，我需要一個(gè)模塊化的Verticle來(lái)測(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>然后， 模塊化事件總線客戶端代碼非常簡(jiǎn)單：
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捆綁包 。 您可以通過(guò)克隆git存儲(chǔ)庫(kù)來(lái)獲取它們：
git clone git://github.com/glyn/vert.x.osgi.git
或通過(guò)下載git repo的zip文件 。
2. vert.x需要Java 7 ，因此請(qǐng)?jiān)O(shè)置終端外殼以使用Java7 。確保正確設(shè)置了JAVA_HOME環(huán)境變量。 （如果現(xiàn)在無(wú)法獲取Java 7，則將捆綁軟件部署到OSGi時(shí)會(huì)看到一些錯(cuò)誤，并且您將無(wú)法在步驟8和9中運(yùn)行示例。）
3.如果您是OSGi用戶，只需在您喜歡的OSGi框架或容器中安裝并啟動(dòng)捆綁軟件，然后跳至步驟8。否則，請(qǐng)按以下方式使用git存儲(chǔ)庫(kù)中的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.如果要嘗試（無(wú)頭的）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ù)庫(kù)。 如果您不想使用MongoDB來(lái)檢查是否進(jìn)行了更新，請(qǐng)查看處女座的日志（在serviceability/logs/log.log ）以查看一些System.out行，例如以下內(nèi)容，該行確認(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之類的工具可見(jiàn)并且可以由其管理。 它還使占地面積最小。
vert.x模塊系統(tǒng)的優(yōu)點(diǎn)是，在各個(gè)頂點(diǎn)之間不存在模塊共享，因此，編寫不當(dāng)?shù)哪K不會(huì)無(wú)意或有意地泄漏獨(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é)人蒂姆·?？怂?#xff08;Tim Fox）問(wèn)我是否正在編寫當(dāng)前容器的替代品，對(duì)此我回答“不是真的”。 我之所以這樣說(shuō)，是因?yàn)槲蚁矚gvert.x的事件驅(qū)動(dòng)編程模型及其線程模型，它們似乎是“容器”的一部分。 但我想更換一對(duì)夫婦的vert.x容器方面：模塊系統(tǒng)和verticles登記處理的方式。
后來(lái)讓我吃驚的是，在模塊化系統(tǒng)中，“容器”作為整體實(shí)體的概念可能有點(diǎn)奇怪，最好考慮多個(gè)單獨(dú)的容器概念，然后以不同的方式組合以適應(yīng)不同的容器用戶。 但是，上面看到的類加載和線程模型之間的微妙交互表明，包含的不同概念可以相互依賴。 我想知道其他人如何看待“容器”的概念嗎？
結(jié)論
由于OSGi框架是一個(gè)相當(dāng)嚴(yán)格的應(yīng)用程序，因此vert.x聲稱它可以嵌入其他應(yīng)用程序中的說(shuō)法已得到驗(yàn)證。
vert.x模塊系統(tǒng)盡管未在模塊之間提供隔離，但確實(shí)在應(yīng)用程序之間（包括垂直模塊及其模塊）提供了隔離，并且使模塊的編寫無(wú)需關(guān)注線程安全。
提出了一個(gè)vert.x問(wèn)題2 ，這應(yīng)該使vert.x易于使用自定義類加載器嵌入其他環(huán)境。
vert.x可以遵循netty，jackson和MongoDB JAR的示例，并在其核心JAR和平臺(tái)JAR中包含OSGi清單，以避免OSGi用戶不得不將這些JAR轉(zhuǎn)換為OSGi捆綁包。 我將這個(gè)問(wèn)題留給其他人提出，因?yàn)槲覠o(wú)法評(píng)估在OSGi中使用vert.x的需求。
在OSGi中運(yùn)行vert.x可以滿足一些出色的vert.x要求，例如如何自動(dòng)化容器內(nèi)測(cè)試（OSGi有許多解決方案，包括Pax Exam，而Virgo有集成測(cè)試框架）以及如何開(kāi)發(fā)verticles并將它們部署到vert .x在IDE的控制下（請(qǐng)參閱Virgo IDE工具指南 ）。 處女座還提供了許多附帶的好處，包括用于檢查和管理束和頂點(diǎn)的管理外殼，復(fù)雜的診斷程序以及更多其他功能（有關(guān)詳細(xì)信息，請(qǐng)參閱處女座白皮書(shū) ）。
該練習(xí)還為處女座帶來(lái)了一些不錯(cuò)的收益。 修復(fù)了370253錯(cuò)誤 ，這是在Java 7下運(yùn)行Virgo的唯一已知問(wèn)題。Virgo3.5依賴于在此環(huán)境中中斷的Gemini藍(lán)圖，因此引發(fā)并修復(fù)了錯(cuò)誤379384 。 我使用了新的基于Eclipse的Virgo工具來(lái)開(kāi)發(fā)各種捆綁軟件并在Virgo中運(yùn)行它們。 結(jié)果，我在工具中發(fā)現(xiàn)了一些小問(wèn)題，這些問(wèn)題將適時(shí)解決。
最后，在Virgo內(nèi)核上運(yùn)行vert.x是對(duì)內(nèi)核是否適合構(gòu)建自定義服務(wù)器運(yùn)行時(shí)的進(jìn)一步驗(yàn)證，因?yàn)楝F(xiàn)在除了Tomcat，Jetty以及在內(nèi)核上運(yùn)行的一兩個(gè)自定義服務(wù)器之外，我們還具有vert.x。
腳注：
參考： OSGi案例研究：來(lái)自Mind the Gap博客的JCG合作伙伴 Glyn Normington 的模塊化vert.x。
翻譯自: https://www.javacodegeeks.com/2012/07/osgi-case-study-modular-vertx.html
總結(jié)
以上是生活随笔為你收集整理的OSGi案例研究：模块化vert.x的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 哈希长度扩展攻击
- 下一篇： 无需部署即可测试JPQL / HQL