web
web開發中的心得
摘要: 今天用jetty做嵌入式web container，來做web項目的integration test，結果發現出現在渲染使用EL表達式的jsp頁面時出現異常：
javax.el.ExpressionFactory.newInstance()Ljavax/el/ExpressionFactory;
檢查了一下，發現javax.el.ExpressionFactory.newInstance()這個方法是EL2.2版本之后才有的方法，而在EL2.1之中是沒有這個方法的，問題很明顯：org.apache.jasper中試圖調用2.2版本的EL，當時提供的EL的版本是2.1版本，所以解決的方式無非就是兩個，要不降低org.apache.jasper的版本，要不提升el的版本。考慮到現在使用的jetty已經是最新的版本8.1.2.v20120308，因此提升EL的版本為2.2更為合適。
閱讀全文
摘要: 有兩年多沒有使用resin了，最近打算在機器上安裝一個web container跑點java web app，同時也可能需要支持php，原本打算用apache + tomcat,apache可以加載php模塊來提供php支持，tomcat作為java web container。但突然想到resin，似乎是可以直接支持php的，而且resin的速度也是稍微快于tomcat，于是跑到resin的官網看了一下，恩，新出了4.0版本(慚愧，兩年前用的是3.0或者3.1)。
決定用resin試試，老朋友了。但是在安裝過程中，發現了一系列問題，尤其是設置開機自動啟動，記錄下來提供大家參考。
閱讀全文
摘要: 修改兩個resin的httpd.sh腳本，加入對JAVA_HOME的不同設置就可以了搞定這個問題，呵呵，最后的方法還是蠻簡單的。
閱讀全文
摘要: 從對resin源碼的追蹤到resin配置文件中的設置，可以明確的看到，resin在設計上是提供了session id 的reuse功能，而且resin.conf默認就是打開reuse的。慚愧的是，我一直不知道......
閱讀全文
摘要: 上文中詳細描述了問題的表現情況，由于這個特性嚴重影響到目前為公司設計的一套前臺統一認證方案，因此不得不特別關注。好在resin的源代碼是公開的，直接從resin的官網將resin的源代碼拿下來，看resin到底是如何處理的。
閱讀全文
摘要: 看到有留言，對我如此“執著”的關注session創建很好奇，解釋一下吧。
首先是關注性能，前面提到過session的使用是有代價的，需要在保存在服務器端內容中，每次request.getSeesion()方法獲取 session時，實際是在服務器段的一個大的hasp結構中以當前的jsessionid為key，獲取對應的value HttpSession對象，這個過程是需要消耗cpu的，當然目前hash算法比較好，這里消耗不那么明顯。而一般的應用，消耗的cpu遠比這個小開銷大出2-3個數量級，因此通常情況不敏感。如果這個session是我們需要使用的，那么付出這些內存和cpu的代碼是完全值得的。但是，如果產生大量的沒有任何用處的"垃圾session"，對大容量，大并發，需要長期穩定運行的系統會帶來很無謂的負載。
閱讀全文
摘要: 按照前面的方法，將jsp頁面加入<%@ page session="false"%>之后，發現還是有新的session會意外的蹦出來。仔細檢查action沒有操作session，那這次是誰干的呢？將目光轉回jsp文件，首先來次狠的，將這個jsp文件的內容刪空為只有純html內容。重新運行后發現不會自動生成session，ok，問題在jsp文件里面了。將原來的內容一點點的加回去，反復測試直到session自動創建的問題再次出現, 哈,發現問題出現在webwork的標簽上。
閱讀全文
摘要: jsp文件是session創建的一個源頭，這里指的不是在jsp文件中用代碼或者標簽來操作session，這些都是在控制中的。容易忽視或者說根本就不會意識到的（比如我，就是寫jsp三年后才發現的)是，jsp有自動創建session的機制，在jsp頁面中，如果沒有明確的給出 <% @page session="false"%>，jsp頁面會非常乖巧（如果剛好需要）或者說是偷偷摸摸（如果不需要）的自動在生成的java文件中增加一句： javax.servlet.http.HttpSession session = request.getSession(true)。
閱讀全文
摘要: 在HttpServlet中，HttpSession對象通常在request.getSession(true)方法調用時才創建。 HttpSession的使用是有代價的，需要占用服務器資源，本著能不浪費就不浪費的原則，我希望系統中的session都在掌握之中，在需要創建時由我們的代碼明確創建。但是最近在開發中發現，新的session對象經常在意料之外出現，究竟是誰在創建session呢？
閱讀全文
摘要: 近期因工作需求探索apache + resin的多機負載分布和多個webapp統一認證的實現方案, 期間設計多個webapp統一認證的實現方案時, 發現resin下通過cookie來傳遞jsessionid和通過url重寫將jsessionid放url中傳遞, 會有細微的差異.
注：后來研究發現是resin提供的session id reuse特性，只是此文第一次發布時我還不知道有此特性，慚愧。
閱讀全文
摘要: 發生在我身上的實際故事，最后發現和axis解析xml時的處理機制有關，namespace的有無會影響xml解析的方式，簡單的說就是有namespace時按照元素名解析，沒有namespace則按照index下標的順序來解析。
閱讀全文
摘要: 在網上找了一些apache下安裝mod_rewrite模塊的文章，說得都很輕巧，但是俺一路碰壁，怎么都出不來。整理了一下，以后再來研究。
閱讀全文
摘要: 前段時間做公司前臺方案的技術探索時，涉及到jsseionid的傳遞，期間嘗試使用resin自己的url rewrite功能來傳遞jsessionid參數，總結如下
閱讀全文
摘要: 前段時間，對公司前臺多機分布方案的做了一些探索，總結了一些東西，貼出來分享。apache + resin的多機部署，類似內容網上比較多，但是都不夠詳細，我第一次弄時費力不少，希望后來人可以更方便一些。
閱讀全文
摘要: RESIN下驗證碼無法顯示的問題，驗證碼的代碼就是google上查找到的最常見的代碼，服務器采用resin部署于linux或unix。不是常見的out.clear()問題，這次的問題發現在一個我壓根就沒有想到的地方，profile DISPLAY 環境變量。
閱讀全文
摘要: 大概在05年6月的時候，我們團隊開始使用webwork來替代struts，剛開始大家都沒有經驗，為了格式化輸出時間和數字，想出了很多現在看來笨笨的傻傻的方法。后來俺找到了這個方法...
閱讀全文