Java Service Wrapper Community Edition

Java服務包裝社區版是已設計從地上爬起來，作為一個可配置的，易於使用的工具部署Java一個完全免費且開放源代碼的命令行應用程序，軟件作為本機UNIX守護進程或Windows背景services.Provides故障修正functionalityIt是一個靈活，可靠和跨平台的軟件，提供故障校正功能，它會自動重新啟動無響應或崩潰的JVM（Java虛擬機）。此外，該軟件提供標準的腳本，方便應用程序的安裝和日誌記錄功能，子進程的管理，定時事件，警告電子郵件，事件的命令，相對內存限制，支持多國語言，以及用戶定義的事件和動作。
社區版是在開源許可發行，它大局;功能是有限的，因為你可以用它來只啟用Java應用程序作為UNIX守護程序運行，重新啟動和監控的JVM，控制進程的優先級，以觸發JVM重新啟動，線程轉儲，和關閉，使用自定義的工作目錄，使用通配符，以及記錄和捕捉JVM控制台output.Getting開始與Java服務包裝社區EditionTo開始使用的Java服務包裝的社區版，下載對應於您的計算機和rsquo的包; S架構，保存歸檔你的主目錄，解壓，打開終端應用程序，進入＆lsquo的位置;箱＆rsquo的;文件夾（如CD /home/softoware/wrapper-linux-x86-64-3.5.26/bin/），並運行＆lsquo的; ./包裝＆rsquo的;命令，該命令將顯示用法信息和可用的命令行options.Runs了廣泛POSIX和UNIX類操作系統systemsJava服務包裝的分佈在三個版本，社區版，標準版和專業版。它與所有的GNU / Linux發行版兼容，但運行在各種POSIX和UNIX類操作系統，包括FreeBSD，AIX，HP-UX，微軟在Windows，Mac OS X和Solaris，支持64位（x86_64的），32位（x86），阿梅爾，ARMHf，SPARC，S390，s390x，安騰，PPC（PowerPC等），以及PA-RISC的硬件平台。

什麼是新的在此版本中：

• 在完善的日誌消息時，請求JVM重啟時的包裝是一個國家，它會被忽略（標準版/專業版）
• 添加額外的調試消息死鎖掃描完成時。但沒有加入的功能變化，可以很容易地告訴多久掃發生在一個給定的應用程序。
• 在清理那裡的環境變量設置的內部跟踪。沒有功能上的改變。
• 在腳本文件的Cygwin檢測用'的uname -o'，一些操作系統的（Solaris和MacOS的，等等）顯示錯誤消息，因為'-o'不是一個有效的參數。現在我們隱藏此錯誤信息，以避免混亂，我們可以猜測的Cygwin沒有運行。
• 添加到控制使用腳本文件systemd運行服務的能力。
• 在Mac OS X上，確定一個錯字，添加另一種替代的方式找到的Java設置JAVA_HOME環境變量，並使用完整路徑的情況下執行的sysctl它不是在路徑。由於達訥爾斯指出這一點。
• 在自定義的包裝時，固定在新版本的Windows中的一個問題。創建目標時，證書不會被刪除。這試圖用新的證書簽署目標時導致的錯誤。
• 在添加缺少的支持，在shell腳本重啟/與launchctl在Mac OS X停止包裝服務。
• 在添加缺少的支持，在shell腳本重啟/與新貴停止包裝服務。
• 添加設置'蘇'命令的路徑以及使用新的SU_BIN和SU_OPTS變量來指定在包裝shell腳本附加參數的能力的能力。
• 在WrapperSimpleApp，WrapperStartStopApp和WrapperJarApp輔助類的地方，導致在JVM上的退出啟動命令行的問題看起來像是意外退出解決的一個問題。這意味著，該包裝會嘗試再次重新發起在JVM而不是在第一次嘗試放棄。
• 修改，使得其使用橫幅將現在只顯示命令行有關的問題WrapperSimpleApp，WrapperStartStopApp和WrapperJarApp輔助類。使用指定的類，方法，或jar文件的問題仍然記錄為錯誤，但顯示的是用戶在這些情況下使用是混亂的。
• 修正WrapperResources.getString（）方法具有這樣的原始字符串，其處理的處理一樣具有替代參數的方法沒有替代參數。現在，所有的字符串由將MessageFormat類在返回之前處理。以前的版本是不是需要逃避單引號是一致的。
• 在添加可選的密鑰驗證，以確保到WrapperResources.getString（）方法傳遞字符串格式正確無誤。看到WrapperResources類信息如何啟用。
• 在添加新的選項屬性wrapper.backend.type：AUTO，SOCKET，SOCKET_IPv4，SOCKET_IPv6，PIPE。當設置為AUTO，該包裝將嘗試打開一個套接字IPv4和退回到IPv6和管道在錯誤的情況下。

不設置區域在啟動時從多字節轉換為寬字符時，
• 修正的bug（僅UNIX）。感謝伯特。
• 添加“CLOSE_BACKEND”別名“CLOSE_SOCKET”作為wrapper.commandfile性測試命令。這是因為已經有多種選擇了一段時間的後端連接，並且該名稱是更加便於攜帶。
• 在運行時，OS X的優勝美地所在的腳本未能正確地進行版本比較'10 0.10'到'10 .5.0“修復Mac上的一個問題。這是導致腳本以為只有32位二進制文件可以運行。這只是一個問題，如果正在使用的包裝二進制文件的增量包命名。
• 在添加新wrapper.java.classpath.missing.loglevel性，這使得它可以控制包裝如何記錄失踪的classpath元素警告。以前，這總是記錄為調試輸出，不能被禁用。
• 如果有推出了不相關的配置或JVM本身的Java進程的任何水平低的問題，該包裝將不再再試一次這樣的重試是毫無意義的。
• 在Windows系統中的API有因為如果它試圖長度超過32767個字符來設置環境變量進程崩潰的一個問題。包裝現在檢查，這和記錄一個錯誤，而不是設置變量。這是一個問題，如果非常大的類路徑中使用時wrapper.java.classpath.use_environment屬性為true。
• Windows不允許命令行為長於在長度32766個字符。不同版本的Windows處理它不同的是提供了這樣一個很長的命令時。包裝現在做自己的檢查，顯示以一致的方式錯誤。
• 在改進UNIX平台上的錯誤信息時，在命令行比系統最大更長。該最大變化很大由平台和環境，難以可靠地計算，因此，最大長度不是目前在該消息中所示的
• 在解決一個問題，在UNIX平台上，其中一個非常大的配置文件可能會導致WrapperManager失敗來啟動。這是通過配置文件經由後端連接部分轉移到WrapperManager引起的。這無論使用何種後端類型會發生。配置文件，將導致改變很大的問題基於特定系統上的大小。
• 在解決一個問題，在Windows平台上，其中一個非常大的配置文件，將不能被發送到WrapperManager在啟動時wrapper.backend.type屬性設置為PIPE。唯一的問題是，WrapperManager.getProperties（）方法是空的。（專業版）
• 在添加檢查到WrapperManager.exec（）在Windows上的方法對32766的最大命令行長度和最大環境變量名稱 - 值對32767（專業版）的長度
• 修正，其中一個免費的NULL指針被正在做的WrapperManager.exec（）調用的清理過程的一部分問題。這是不知道造成任何問題。
• 添加getStdOut（），getStdErr（），和getStdIn（）方法的WrapperProcess類作為別名到的getInputStream（），getErrorStream（），和的getOutputStream（）方法來幫助避免混淆。
• 在解決一個問題，在Windows 7中長日誌線後得到了字31397損壞時wrapper.console.direct是真實的。這似乎是與底層的Windows API的一個問題，是唯一一個顯示問題。減少可寫入與單個API調用來30000來解決此問題的最大字符數。這種變化是內部的，但還有上線記錄的長度沒有限制。
• 修正了一個僵局，如果包裝沒有寫入到後端的時候wrapper.backend.type屬性為PIPE。通過代碼審查發現，不知道實際上發生了。
• 從的Mac OSX 10.5.0，該腳本文件將使用launchctl配置文件中的關鍵“的KeepAlive”。 Mac OSX版之前的版本將繼續使用相同的密鑰'按需'。感謝羅賓指出這一點。（標準版/專業版）
• 在不允許使用主機標識託管在OS X系統中的虛擬化的Windows系統上運行時綁定到蘋果的藍牙設備。
• 在解決一個問題，即WrapperManager.log（）不正常工作時，已記錄多字節消息。
• 在調試輸出完整的配置屬性包從日誌輸出抑制，因為它是巨大的，可能包含敏感數據。添加一個大小縮寫輸出，以協助調試。
• 修正在UNIX平台上的內存洩漏時的錯誤消息進行了報導。這只是一個問題，如果該消息被重複記錄。

通過代碼審查發現
• 修正了幾個其他潛在的內存洩漏。不知道已經造成任何實際問題。

什麼是3.5.23版本的新：

• 在標準版/專業版：
• 當一個未知的許可證類型遇到，包括未知類型的錯誤信息，以幫助調試。
• 解決內存損壞問題時的語言設置為日語等雙字節語言環境的z / OS。
• 在穿過，使包裝更耐用嚴重時編碼的雙字節字符遇到。
• 在Preofessional版：
• 修改拋出的異常的時候WrapperManager.exec（）被調用，而包裝是關機，因此現在說，而不是說，沒有加載本地庫。
• 在包裝現在更小心，以確保後端是永遠不會關閉，而一個子進程正在啟動，以確保包裝知道發動所有的子進程。
• 添加一條警告消息的情況下推出的一個子進程中，由於後端的連接被關閉的包裝不通知。
• 修正，而閱讀stdout或stderr輸出一個子進程，而包裝被關停後的子進程退出可能會引發潛在的NPE。
• 修正在UNIX平台上的問題，我們在那裡卡住這是當前阻止從標準輸出或標準錯誤讀取過程後，試圖清除。
• 修正在UNIX平台上，其中超時試圖獲取子進程列表的內部鎖被引起內部計數器不同步的問題，導致了其他終止子進程被留下作為解散的殭屍，直到Java進程終止。
• 在解決一個問題，在哪裡使用的子進程通信的管道文件描述了被不正確地傳遞給所有的子進程的UNIX平台。他們沒有增長一段時間。
• 在FreeBSD系統中的wrapper.lang.encoding沒有解決，以UTF-8正確時沒有設置LANG環境變量解決問題。
• 修正了一個潛在的同步問題，調用WrapperProcess.waitFor（）或WrapperProcess.exitValue（）。
• 添加額外的調試日誌輸出，顯示不同的超時值，以幫助用戶調試的問題。
• 在解決一個問題，shell腳本沒有正確檢測到操作系統版本與Mac OSX特立獨行。
• 添加警告有關未定義環境變量中包含在配置文件中的文件引用。
• 在添加支持環境變量擴展與wrapper.java.additional_file和wrapper.app.parameter_file屬性所指定的文件。
• 在糾正整數的WrapperUNIXGroup.toString（）方法格式化因此它與包裝的其餘部分保持一致。
• 在解決一個問題，其中的iconv庫的要求不能得到滿足了FreeBSD 10.我們現在動態通過尋找/usr/local/lib/libiconv.so定位庫，/usr/local/lib/libbiconv.so或/lib/libkiconv.so.4的順序。
• 解決的WrapperPrintStream.println（）方法，因此含有換行字符串將有正確的每一行前綴與配置的頭。

什麼在3.5.14版本是新的：

• 在一個固定在AppCommand.bat.in問題文件，其中，在包裝的二進制的文件名的括號會造成一個＆QUOT;路徑是出乎意料的，此時＆QUOT;錯誤。
• （標準版/專業版）
• 在使用Windows上的64位平台，其中包裝將繼續使用，即使wrapper.lang來指定不同的語言系統默認語言包裝的本地化版本時，解決問題。 3.5.12中引入的。
• 在那裡的“狀態”命令被錯誤地報告為在使用輸出'查詢'Windows的AppCommand.bat.in命令基於批處理文件中解決問題。 “狀態”命令，一直工作正常，如果使用。
• 修正在UNIX平台上的問題，在一些異步消息被引起的警告消息＆QUOT;編碼錯誤...＆QUOT;代替預期消息的被記錄。這可以看出，如果配置的日誌文件沒有寫權限。以外的不正確的日誌消息，該包裝工作正常。在3.5.2推出。
• 在UNIX腳本，與暴發戶是不正常的時候RUN_AS_USER設置運行解決問題。
• 在運行針對UNIX shell腳本的“狀態”命令時，所以它現在允許任何用戶運​​行該腳本來執行pid文件的只讀檢查放鬆安全檢查。
• 解決問題的UNIX腳本，“刪除”命令試圖停止應用程序沒有安裝，即使正在運行的應用程序。
• 修正了一個緩衝區溢出指定wrapper.ntservice.account當Windows服務的安裝過程中，這有可能導致崩潰。這被引入3.5.12。
• 在解決可能發生在啟動和可能導致崩潰堆損壞。僅在Windows系統，它使用的系統事件日誌，受到影響。從代碼審查發現，還沒有過的用戶，這導致問題的報告。這可能發生，如果配置wrapper.log不能寫入的包裝總是試圖寫入事件日誌在這種情況下。 3.5.12中引入的。
• 添加UNIX shell腳本和包裝之間的一個新的版本相比，開機有顯示的情況下的版本不匹配的警告。如果shell腳本和包裝都是每人至少版本3.5.14檢查只會工作。
• 在增加了一個新的wrapper.pidfile.strict屬性，它會告訴包裝不啟動，如果已經存在的pid文件。默認為false向後兼容性。
• 請後端套接字的Java端的情況下讀取或寫入超時更有彈性。後端套接字沒有超時默認設置所以這應該不會有問題。一對夫婦用戶報告在特定系統上的問題卻導致此修復程序。
• 為了有助於在後端插座超時的檢測，一個新wrapper.backend.so_timeout系統屬性的加入使有可能配置在後端插座使用一個超時。看到WrapperManager.exec的Javadoc中（）類的細節。

什麼在3.5.11版本是新的：

• 在修復Windows上的潛在的崩潰引起的一個緩衝溢出。自3.5.0版本這是一個問題，影響到它的配置定義多個wrapper.ntservice.dependency ..根據什麼是在內存中，這並不總是導致崩潰。它有一個給定的配置文件非常重複性的行為。
• 在修復Windows上的問題，其中包裝是服用15秒或更長時間，以啟動在某些系統上，因為的WinVerifyTrust系統調用中有更新CRL問題。這曾經是一個問題，因為包裝的二進制文件開始在3.5.7版本被簽署。如果調用的WinVerifyTrust時間超過配置的wrapper.startup_thread.timeout那麼包裝將繼續毫不拖延地啟動。
• （標準版/專業版）
• 在自定義明確在刪除定制二進制的證書。有辭職的另一個證書二元否則問題。
• 如果包裝是無法寫入配置wrapper.logfile以任何理由，然後我們總是回落到一個默認的日誌文件，然後記錄消息有關失敗。如果默認也失敗，那麼，它也記錄但該消息將只被記錄到，在大多數情況下，控制台。修改包裝，所以我們現在總是同時發送信息到系統日誌或事件日誌，無論什麼樣的wrapper.syslog.loglevel設置為。這一點很重要，以幫助追查日誌文件訪問問題的原因。
• 使用3.5.0版開始，它是在內部能夠打印出多行的日誌消息，使得所有的線總是被組合到一起，在日誌文件中。這個版本修改記錄代碼略微使得這種多線日誌輸出現在記錄為在UNIX sylog或Windows事件日誌的單個消息。
• 解決一個問題，即從JVM非常長的行輸出將導致包裝出現掛起一段時間。第一時間記錄包含幾十萬字的輸出單行，內部緩衝區正在逐步增加每週期100個字符。該包裝現在增加基於上次已知尺寸大大減少所需選擇一個新的緩衝區大小的週期數的大小。
• 修改PAUSE_THREAD命令，所以現在可以無限期地等待。唯一有用的測試包裝。
• 在添加新PAUSE_LOGGER命令來使人們有可能暫停下一個日誌條目。唯一有用的測試包裝。
• 在UNIX，JVM和包裝之間的標準輸出/標準錯誤管道沒有被正確地清理。這就產生了一個小漏洞，但在其他方面無害的。管道現在清理，並為每個JVM實例初始化。
• 在解決一個問題，即在包裝可能無法重新啟動JVM的時候重啟請求起源於JVM如果系統正經歷導致長時間磁盤IO隊列非常沉重的IO。這是使包裝的主循環到框上的寫和錯過重起請求，使所述包裝關機，而不是重新啟動。這可能會影響到所有平台。在Windows中，它也可以通過選擇在控制台凍結輸出，然後發出請求的JVM內重啟轉載。
• 在添加新WrapperPropertyUtil輔助類，使其easer從JVM中訪問封裝的屬性值。
• 修正在某些平台上的Java在那裡日誌輸出可能會被損壞，由於一個函數strncpy系統功能使用不當的錯誤。該功能警告說，一些實現不支持重疊的內存拷貝。下面的輸出的一個空行的問題只能被再現一個Linux試驗機上在線。 3.4.0以來這個問題一直存在。

什麼是3.5.9版本，新的：

• 在修復Windows上的問題，在網絡適配器的名字包含＆QUOT; PRO / 1000＆QUOT;從主機標識的列表中被刪除時顯示＆QUOT; wrapper.exe -h＆QUOT;被運行。這並沒有影響到報告3.5.7或更早版本，或開發許可證密鑰產生的主機標識現有服務器的許可證密鑰文件。但它確實會導致包裝報告，當包裝未經授權的文件啟動沒有有效的主機標識可以找到。這是通過一些測試代碼3.5.8補充說，我們無法刪除而引起的。
• 在解決一個問題，即包裝不正確產生控制權交還給它的主循環時，正在從JVM記錄非常大量的連續輸出。在3.4.0版本中引入。在之前的版本3.5.8，這可能會造成的JVM超時並重新啟動本身。特定的問題得到了解決，但在3.5.8包裝過程中仍然會一直反應遲鈍的時候，這是發生。包裝將現在經過250毫秒連續記錄總是性狀的回其主循環。
• 修正了一個問題，即WrapperManager可以阻止試圖寫入調試輸出，如果當前用戶應用程序編寫非常大量輸出到控制台為好。在極端的情況下，這導致了包裝以為JVM被凍結。這只是一個問題，如果啟用調試輸出。
• 在重組的shell腳本，因此所有版本，現在再次使用相同的腳本。

什麼是3.5.8版本，新的：

• 在（標準版/專業版）
• 在與3.5.5版本開始，我們無效使用的所有00FF *在Windows主機標識，以避免與不斷變化的主機標識時，用戶可以在他們的系統中的瞻博網絡連接的網絡適配器。事實證明，這是過於嚴格的下Parallels客戶操作系統上運行也利用這個主機標識範圍。包裝現在更謹慎地只無效實際瞻博網絡連接的主機標識。
• （標準版/專業版）
• 在提高向用戶顯示信息時的包裝是無法找到任何主機標識的系統。
• 修正了在Solaris上，那裡的選項-F不可用grep的包裝腳本的一個問題。
• 在包裝調試輸出添加了Windows版本的信息。
• 在增加了一個wrapper.log.warning.threshold屬性，它使包裝顯示警告每當它檢測到包裝花了很長時間來記錄日誌信息。此溶液中加入上測試非常重負載系統引起的緩慢的IO一個報告的問題。
• 在解決一個問題，即要求JVM重啟過濾器會被忽略，如果JVM立即退出自身。包裝是現在比較一致的，因此從JVM或過濾器內重啟請求將始終優先於這種退出的請求。外部關閉請求，或從其他行動仍將表現為他們在過去沒有，繼續關閉包裝。包裝還記錄調試輸出消息，如果一個優秀的重新啟動請求被保存或忽略。
• 修正了一個可能發生在某些Windows平台具有一定的多字節編碼系統的AppCommand.bat批處理文件中存在的問題。該腳本已被重寫和可疑部位進行了簡化。腳本的功能已被保存。
• 由環境變量WRAPPER_CONF_DIR，其可以用於配置屬性。 （功能要求3160644）
• 在運行該腳本為不同的用戶，在指定RUN_AS_USER時所做的腳本退出與正確的退出代碼接收。 （錯誤報告3185281）
• 在解決訪問衝突可能發生在代碼簽名證書並沒有被證實。
• 請一個錯誤，如果後端接口被強制關閉外部。它已被越來越處於調試日誌級別記錄。該消息是＆QUOT;現有的連接被強行關閉遠程主機。 （0x2746）＆QUOT ;.因為如果啟用調試輸出只記錄消息時，JVM將與沒有明確的解釋，在重新啟動發生了什麼事。插座封閉源正在調查中。
• （專業版）
• 添加Java調用fireUserEvent到WrapperManager API。這使得用戶觸發郵件的事件，行動沒有過濾器的觸發。還請找到該呼叫在安全網頁的安全模型的更多細節。
• 修正在Mac版本的一個警告，如果配置的java命令並不是一個通用二進制。支票中添加了3.4.0，以確保該wrapper.java.command運行腳本時直接指向一個可執行文件，以避免意外行為。該消息僅僅是一個警告和包裝繼續不顧。標準的PPC，ppc_64，x86_64的，I386，以及通用的二進制文件現在都將正常工作沒有警告。
• 包裝物的默認值。*。umask的屬性是用當前的umask進程有。以前的默認值總是0022。
• 在添加用於控制包裝是否使用了傳統的和QUOT的JVM通信的新wrapper.backend.type財產; SOCKET＆QUOT;或者新的實驗和QUOT; PIPE＆QUOT ;.這增加了作為一個解決方法，其中一些Windows機器關閉套接字在操作系統級別難得一見的問題。這只是見過在Windows 2003，但也存在於其他Windows版本也是如此。
• 在添加一個新的實驗wrapper.use_javaio_thread屬性，它會導致包裝來處理所有的java控制台輸出在一個專用的線程。
• 在添加新WrapperManager.isNativeLibraryOk（）方法，它可以讓用戶輕鬆的代碼測試本機庫是否被加載並在啟動時初始化。
• 在添加新PAUSE_THREAD命令到wrapper.commandfile財產這使得它可以測試包裝的行為時，各個線程阻塞或凍結。這被用來模擬和再現上大量的IO綁定服務器的問題。
• 在提高，當包裝不能ping通JVM為長時間的包裝的Java端的行為方式。在JVM用於退出來讓自己重新同步自己的JVM。這是造成上是大量IO綁定，因為包裝可能阻止了一段時間，而試圖寫入日誌文件和JVM在退出系統的問題。 JVM將現在這樣的情況下從來沒有退出。 JVM將永遠不會成為孤立的，因為它仍然會退出幾乎立刻如果後端插座或管道的包裝也在不斷關閉。
• 棄用所述WrapperManager.appearOrphan（）方法，因為它是用於模擬的故障模式，該模式不再可能與包裝
• 在改變了包裝正在處理有關代碼簽名/時間戳證書的錯誤的方式。包裝現在只有關機本身如果二進制的簽名沒有成功驗證，因為二進制或簽名已被畸形但如果用反簽名的任何問題已被發現。與3.5.7開始，Windows的包裝二進制文件簽名。與鎖定的Windows 2008系統用戶的一些有問題的包裝拒絕啟動，因為科摩多證書已被禁止在他們的系統。
• 添加新wrapper.java.detach_started屬性，這使得有可能使用的包裝作為一個簡單的工具來啟動Java應用程序。當啟用時，包裝立即終止，並JVM留給獨立運行。
• 在運行時將包裝作為指定的用戶帳戶，通過wrapper.ntservice.account財產，包裝將增加權限的帳戶自動安裝時登錄的服務。 （功能要求＃3286491）

什麼是3.5.6版本，新的：

• 在固定在UNIX平台上的問題，即日誌文件路徑正在不正確地計算，如果一個絕對路徑是為wrapper.logfile指定，並且該文件不存在。顯示一條警告消息，但該包裝將繼續使用默認的日誌文件。有消息顯示，造成在某些平台上崩潰包括的Mac OSX中存在的問題。在3.5.5版本中引入的。
• 修正在Windows平台上的問題，即包裝就會崩潰，如果它不能訪問配置wrapper.logfile的目錄。在3.5.5版本中引入。錯誤＃3087424。
• 改善當有寫入到配置wrapper.logfile問題，使該消息現在將登錄到該包裝最終使用情況下，它是成功的在回落至一個默認的日誌的日誌文件警告記錄的方式文件中。
• 在Windows平台上解決了一個問題，wrapper.java.additional。被指定的命令行上，並載空間特性，建立Java命令行的時候並沒有被正確地重新報價。在3.3.6版本中引入的。
• 在解決一個問題，即警告消息記錄為wrapper.java.additional無效值。物業，包含損壞的文本。在3.3.6版本中引入的。
• 在解決一個問題，在UNIX平台上，其中的wrapper.java.additional無效值。財產被正確地被報導，然後跳過，但啟動JVM所產生的命令行有這樣是導致JVM失敗推出一個空值。無效值是不以A＆QUOT任何值; - ＆QUOT;性格。
• 添加可用於引用從該包裝被發射的工作目錄的新WRAPPER_INIT_DIR環境變量。這是需要一定的應用，因為該包裝總是改變其工作目錄的包裝二進制文件的位置。
• 修改UNIX shell腳本，使其不再改變當前工作目錄到腳本的位置。這不再是必需的，因為包裝已經改變工作目錄到它自己的位置，因為3.2.0版本。
• 在添加新wrapper.request_thread_dump_on_failed_jvm_exit.delay屬性來控制包裝多久做一個線程轉儲殺死Java進程之前之後等待。這種延遲一直硬編碼為5秒。
• 在清理的無效配置值幾個警告信息的文字，使其更加一致。
• （專業版）
• 添加新wrapper.jvm_kill.delay屬性，這使得有可能控制所需的時間量，以允許jvm_kill事件被觸發和JVM實際上被殺死之間。
  
  
  
  
  

要求：

• 在甲骨文的Java標準版運行環境