BEA使用的是Catalina,也就是tomcat，無意中發現一個非常隱蔽的也許不算致命的BUG，在JSP中某處的標簽如果執行錯誤，會在前面某處輸出緩沖區時無異常退出，而不是在真實錯誤地點發出錯誤異常。
10：45 分：卻發現FormTag執行異常退出，而且錯誤日志沒有任何輸出；所以決定轉過去先看看是什麼回事。非常奇怪的是，就算在doEndTag中輸入斷點後，錯誤日志仍沒有輸出。最後的檢查結果，不是程序有錯，而是在某種條件下，tag對output沒有響應，所要求輸出的vaildatorscript 只輸出了一半。
這個tag集成了struts.validator的JavascriptStaticTag，不知有沒有人這樣做：我不想花時間重修把它的代碼解剖出來，也不希望讓前台的頁面多幾個需要配置的tag;於是直接用上級的FormTag向它置值，然後直接調用它的DOStartTag()——其實，在 JSP容器中不也是這樣按注冊記錄調用它的方法嗎？此前偶而發現有這樣的錯誤，不過轉眼就恢復正常。既然異常消失，錯誤日志也沒有記錄，也就無法發掘它的錯誤來源了。這次重新出現，引起我的注意，而且錯誤持續時間比較長，於是可以在程序中設置斷點，跟蹤它的錯誤發生的位置。
結果，錯誤源集中到了不是我寫的，來自於struts的validator的這個標簽。對於struts這樣的中間構件，我現在的態度是如果我不能完看懂它的代碼，可以在裡面設置斷點記錄輸出到錯誤日志degbug，就不加采用，所以現在我手中的struts只是有它的構件功能，使用方式與一般所見的struts已經是完全不同了，這也包括了這個JavascripStaticTag。對於它的用法，我是希望它作為程序的一部分，當我選定要對某個表單的客戶端進行驗證時，它自動完成所必需的代碼輸出，而不需要我手工地設這個TAG，還要匹配它的調用函數名稱。這個集成是成功的，已經運行了很長時間，經常了一定強度的測試，但平心而論，對於其中的代碼我仍是沒有深入。
錯誤的產生後我打算向緩沖區輸出斷點，這是由於這個程序是向頁面輸出validator-rules.xml中的javascript代碼，但發現沒有成功，許多斷點沒有輸出；表明程序輸出是中斷的，但輸出過程是正常的，否則錯誤日志會記錄下來。進一步的驗證表明，程序運行以及從內存記錄中獲得的 Javascript是完整的，從而排除了讀取XML發生錯誤的可能性，而且也證明JAVA程序的運行是完全正常的，錯誤不在開發者程序，而在於平台本身，在輸出緩沖區時無異常退出了！！！由於JavascriptTag中是使用stringBuffer最後toString再輸出到緩沖區，或者，是由於這個量太大，所以溢出了？？於是我把它分成逐段都輸出，但結果完全一樣。也許是由於我對於它的調用不是由容器進行，直接由parent-TAG調用方法造成緩沖區分配較小？？於是改成getString方法，由parent完成輸出，可是，結果仍然是一樣的。
最後，我打算先越過這一步，看看執行結果如何，發現該頁由於BSelectTag由於調關聯的BaseIf接口昨晚錯刪除了一個方法出現異常，於是重新編譯後，再執行，結果發現上面的錯誤消失了。重新恢復這個錯誤，異常重新出現。這樣也就發現了它的原因。事實上，BEA使用的是CATLINAJSP 容器，解釋一個JSP頁面時是一個統一的過程。這個異常表明，在JSP中前後的輸出文本生成是相關聯的，位於後面的程序運行錯誤，象這裡，是在後面運行時出現了methodnofound(我估計，因為即使是服務器日志也沒有發現錯誤記錄)，也令這個解釋執行過程中斷，造成緩沖區文本輸出一半無異常退出。
我很少處理JSP，這是一個經驗，如果出現這種緩沖異常輸出而程序捕捉不到任何的錯誤日志時，先把這個頁面相關的程序都編譯一遍，排除這個可能再說。
這個問題整整花了我兩個小時找原因，的確隱蔽，一些副作用是這樣就對validator.Javascript的代碼熟悉了，項目後面有點時間的話，就把它修改一下，只輸出這次需要的驗證方法script：我總覺得它輸出了太多的東西，把validator_rules.XML中的所有 script方法全送出來了。
