Struts架構中的Session對象建立和控制

        首先談一下對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中設定<%@ page session="false"%>.

　　（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（）方法原型如下：

　　程式碼：

　　此類在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.

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);
        }
    }