首先談一下對session對象在web開發中的創建以及sessionId生成並返回客戶端的運行機制
session對象當客戶端首次訪問時創建一個新的session對象並同時生成一個sessionId並在此次響應中將sessionId以響應報文的方式些回客戶端浏覽器內存或以重寫url方式送回客戶端來保持整個會話只要sever端的這個session對象沒有銷毀以後再調用requestgetSession（）時就直接根據客戶端的sessionId來檢索 server端生成的session對象並返回不會再次去新建除非根據此sessionId沒有檢索到session對象
下面是在IE下測試因為IE的一個BUG就是IE的隱私設置即使是阻止所有cookie時也還是會以會話cookie來保存sessionId所以下面都是以會話cookie來討論的
（）在server沒有關閉並在session對象銷毀時間內當客戶端再次來請求server端的servlet或jsp時將會將在第一次請求時生成的sessionId並附帶在請求信息頭中並向server端發送 server端收到sessionId後根據此sessionId會去搜索（此過程是透明的）server對應的session對象並直接返回這個 session對象此時不會重新去建立一個新的session對象
（）當server關閉（之前產生的session對象也就消亡了）或 session對象過了其銷毀時間後浏覽器窗口不關並在本浏覽器窗口再次去請求sever端的servlet和jsp時此時同樣會將 sessionId（server關閉或session銷毀時生成的sessionId）發送到server端server根據sessionId去找其對應的session對象但此時session對象已經不存在此時會重新生成一個新的session對象並生成新的sessionId並同樣將這個新生成的sessionId以響應報文的形式送到浏覽器內存中
（）當server沒有關閉並session對象在其銷毀時間內當請求一個 jsp頁面回客戶端後關閉此浏覽器窗口此時其內存中的sessionId也就隨之銷毀在重新去請求sever端的servlet或jsp時會重新生成一個sessionId給客戶端浏覽器並存在浏覽內存中
上面的理論在servlet中測試都是成立的下面談一下在struts框架下進行上面的測試時的不同的地方
先簡要說下測試程序的流程
客戶端請求indexdo——>進入server端的IndexAction——>轉向loginjsp頁面——>請求logindo——>進入server端的LoginAction
首先說明IndexAction中沒有去產生session對象loginjsp中設置<%@ page session=false%>
（）環境servlet + jsp
在sevlet+jsp測試跟蹤時在indexdo進入IndexAction 後轉向loginjsp時此時浏覽器內存中是沒有會話cookie的那麼在loginjsp上請求logindo進入LoginAction 後用requestgetCookies（）測試時其值是為null的！結果是穩合的因為從始置終沒有產生過session嘛！
（）環境struts + jsp
在struts+jsp測試跟蹤時跟上面的流程一樣開始想結果也應該是一樣的 但經過調試後發現結果卻不是所想的那樣在logindo進入LoginActoin後用用requestgetCookies（）測試時發現其值不為null即其有name和value開始很不理解因為根本就沒有創建過session對象哪來的會話cookie值呢但是結果有那麼想著此時浏覽器內存中也就應該有會話cookie問題就在這裡！從哪裡來的？
後來經過仔細考慮後想到struts中的特點我們自己寫的Action類是繼承struts的Action的而且之前是經過struts的中央控制器ActionServlet來控制轉向的所以我想肯定是在程序進入我自己寫的 IndexAction之前struts框架中的代碼肯定已經創建了session對象並已經生成了sessionId於是就找到相關書籍查看了 ActionServlet工作流程以及調用哪些類看了之後果然在其中看到了HttpSession session = requestgetSession（）這樣一句話！於是答案也就明了了
大家知道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 (!moduleConfiggetControllerConfig()getLocale()) {
return;
}
// Has a Locale already been selected?
HttpSession session = requestgetSession();
if (sessiongetAttribute(GlobalsLOCALE_KEY) != null) {
return;
}
// Use the Locale returned by the servlet container (if any)
Locale locale = requestgetLocale();
if (locale != null) {
if (logisDebugEnabled()) {
logdebug( Setting user locale + locale + );
}
sessionsetAttribute(GlobalsLOCALE_KEY locale);
}
}
此類在struts configxml配置文件中有對應的配置項 < 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 = requestgetSession（）其也是RequestProcess類中的processLocale（）方法生成的此時其session 的isNew也還是true因為還沒有返回客戶端其是新創建的那麼按照上面的流程當在loginjsp上通過logindo進入 LoginAction後其requestgetCookies（）固然也就有值了！並且其值是RequestProcess類中的 processLocale（）方法產生session對象時生成的
如果我們在strutsconfigxml中加上< controller locale=false>< /controller> 時此時如果再根據上面的流程來跟蹤程序並在LoginAction用requestgetCookies（）測試時其值是為null的當然在 IndexAction寫上HttpSession session = requestgetSession（）時其是進入IndexAction時新創建的isNew也是true
From:http://tw.wingwit.com/Article/program/Java/ky/201311/28281.html
