web server 的環境:
有一個功能是使用者按下按鈕後,web server 會用 JNA 載入印表機的 DLL,然後以程式控制列印內容。印表機不是實際連接到 web server,而是用網路印表機的方式連到 LAN 上頭某台使用者的 PC。在開發的時候沒有出現問題。去年列印內容小改版之後,在公司的測試環境也沒有問題(不過這段是同事幫改的,非親身經歷)。這個月正式在客戶那邊上線,印表機卻完全不會動……
◢▆▅▄▃ 崩╰(〒皿〒)╯潰 ▃▄▅▆◣
在各種測試環境 / 機器排列組合當中,都有作下面兩個測試,結果都一樣:
在客戶那裡失敗,於是印表機撤回來,在公司重作 lab,結果原本可以列印的機器環境也出現同樣的狀況…
◢▆▅▄▃ 崩╰(〒皿〒)╯潰 ▃▄▅▆◣
因為中間卡了一層 DLL,然後這 DLL 也有 32 / 64bit 的版本,所以 web server 跟接印表機的機器有準備 32bit / 64bit OS 作交叉測試。(接印表機的 OS 我沒有特別留意,好像都是 Window 7 吧)
OS 版本的交叉測試都失敗之後,想說既然獨立的 Java application 可以印,那是不是 Tomcat 作了什麼手腳?那我繞一圈用 ProcessBuilder
去執行那個 Java application 來列印總可以吧?結果一樣死掉……
◢▆▅▄▃ 崩╰(〒皿〒)╯潰 ▃▄▅▆◣
這個時候,同事在他的開發環境上可以讓 web server 執行列印的動作(我一直沒有測我的開發環境 XD),崩潰之餘,我終於想到一個可能性……
難道是 Tomcat 變成 Windows service 才會發生這種事情?
實際 production 的環境,把 Tomcat 變成 Windows service 完全合情合理。這麼多年下來也沒出現過問題(看看這精美的 Tomcat 版本就知道了)。所以也一直沒去懷疑他(尤其同事之前在測試環境上一切正常)。
好,把 Tomcat service 停掉,改成用原始 startup.bat
的方式啟動,一切又都天下太平了。
◢▆▅▄▃ 崩╰(〒皿〒)╯潰 ▃▄▅▆◣
在 Tomcat service 版的執行環境下,程式會卡在 openport()
上頭,而且沒有任何錯誤訊息或是 alert 視窗,就是單純停在那裡。
在正常執行環境下,如果 openport()
給了一個錯誤的連線資訊,會跳出一個 alert 視窗「Printer Driver is not been specified」