首先谈一下对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
