首先談一下對session對象在web開發中的創建以及sessionId生成並返回客戶端的運行機制.
session對象當客戶端首次訪問時,創建一個新的session對象.並同時生成一個sessionId,並在此次響應中將sessionId以響應報文的方式些回客戶端浏覽器內存或以重寫url方式送回客戶端,來保持整個會話,只要sever端的這個session對象沒有銷毀,以後再調用request.getSession()時就直接根據客戶端的sessionId來檢索server端生成的session對象並返回,不會再次去新建,除非根據此sessionId沒有檢索到session對象.
下面是在IE下測試,因為IE6.0的一個BUG就是IE的隱私設置即使是阻止所有cookie時,也還是會以會話cookie來保存sessionId.所以下面都是以會話cookie來討論的,
(1)在server沒有關閉,並在session對象銷毀時間內,當客戶端再次來請求server端的servlet或jsp時,將會將在第一次請求時生成的sessionId並附帶在請求信息頭中並向server端發送,server端收到sessionId後根據此sessionId會去搜索(此過程是透明的)server對應的session對象並直接返回這個session對象,此時不會重新去建立一個新的session對象.
(2)當server關閉(之前產生的session對象也就消亡了),或session對象過了其銷毀時間後,浏覽器窗口不關,並在本浏覽器窗口再次去請求sever端的servlet和jsp時,此時同樣會將sessionId(server關閉或session銷毀時生成的sessionId)發送到server端,server根據sessionId去找其對應的session對象,但此時session對象已經不存在,此時會重新生成一個新的session對象,並生成新的sessionId並同樣將這個新生成的sessionId以響應報文的形式送到浏覽器內存中.
(3)當server沒有關閉,並session對象在其銷毀時間內,當請求一個jsp頁面回客戶端後,關閉此浏覽器窗口,此時其內存中的sessionId也就隨之銷毀,在重新去請求sever端的servlet或jsp時,會重新生成一個sessionId給客戶端浏覽器,並存在浏覽內存中.
上面的理論在servlet中測試都是成立的,下面談一下在struts框架下進行上面的測試時的不同的地方.
先簡要說下測試程序的流程:
客戶端請求index.do--->進入server端的IndexAction--->轉向login.jsp頁面----->請求login.do----->進入server端的LoginAction.
首先說明:IndexAction中沒有去產生session對象,login.jsp中設置.
(1)環境servlet + jsp:
在sevlet+jsp測試跟蹤時,在index.do進入IndexAction後轉向login.jsp時,此時浏覽器內存中是沒有會話cookie的,那麼在login.jsp上請求login.do進入LoginAction後,用request.getCookies()測試時,其值是為null的!結果是穩合的,因為從始置終沒有產生過session嘛!
(2)環境struts + jsp:
在struts+jsp測試跟蹤時,跟上面的流程一樣,開始想結果也應該是一樣的,但經過調試後發現結果卻不是所想的那樣.在login.do進入LoginActoin後用,用request.getCookies()測試時,發現其值不為null,即其有name和value,開始很不理解,因為根本就沒有創建過session對象,哪來的會話cookie值呢.但是結果有,那麼想著此時浏覽器內存中也就應該有會話cookie,問題就在這裡!從哪裡來的?
後來經過仔細考慮後,想到struts中的特點,我們自己寫的Action類是繼承struts的Action的,而且之前是經過struts的中央控制器ActionServlet來控制轉向的,所以我想肯定是在程序進入我自己寫的IndexAction之前,struts框架中的代碼肯定已經創建了session對象並已經生成了sessionId.於是就找到相關書籍查看了ActionServlet工作流程以及調用哪些類,看了之後果然在其中看到了HttpSession session = request.getSession();這樣一句話!於是答案也就明了了.
大家知道struts的ActionServlet類中在接收到我們客戶端的請求(*.do)後(之前會做一系列初始化工作),並不是直接去處理我們的請求並調用相應的Action(我們寫的如IndexAction),而是將處理工作交給RequestProcessor類,其process方法中會調用一系列的方法來完成相應的請求處理和轉向操作.其中有一個方法引起了我的關注,就是processLocale()方法.
Struts框架:RequestProcess類中的processLocale()方法原型如下:
程序代碼:
protected void processLocale(HttpServletRequest request,
HttpServletResponse response) {
// Are we configured to select the Locale automatically?
if (!moduleConfig.getControllerConfig().getLocale()) {
return;
}
// Has a Locale already been selected?
HttpSession session = request.getSession();
if (session.getAttribute(Globals.LOCALE_KEY) != null) {
return;
}
// Use the Locale returned by the servlet container (if any)
Locale locale = request.getLocale();
if (locale != null) {
if (log.isDebugEnabled()) {
log.debug(" Setting user locale '" + locale + "'");
}
session.setAttribute(Globals.LOCALE_KEY, locale);
}
}
此類在struts-config.xml配置文件中有對應的配置項: < controller locale="true">< /controller> 其缺省狀態locale屬性的值為true,也就會調用processLocale方法,並在第一次請求時創建session對象和生成sessionId.但改為false後,在第一次請求到達ActionServlet後不會調用processLocale方法,也就不會生成session對象了。
結果也就出來了，在struts應用中,*.do到達server端後經過ActionServlet後轉想我們自己寫的IndexAction之前, < controller locale="true">< /controller>(缺省狀態) 時,就已經產生了session對象和sessionId,這是struts框架類中生成的,即使我們在IndexAction中寫上HttpSession session = request.getSession();其也是RequestProcess類中的processLocale()方法生成的,此時其session的isNew也還是true,因為還沒有返回客戶端,其是新創建的,那麼按照上面的流程,當在login.jsp上通過login.do進入LoginAction後,其request.getCookies()固然也就有值了!並且其值是RequestProcess類中的processLocale()方法產生session對象時生成的.
如果我們在struts-config.xml中加上< controller locale="false">< /controller> 時,此時如果再根據上面的流程來跟蹤程序,並在LoginAction用request.getCookies()測試時,其值是為null的,當然在IndexAction寫上HttpSession session = request.getSession();時其是進入IndexAction時新創建的,isNew也是true。
