首先谈一下session对象在web开发中的创建以及sessionId生成并返回客户端的运行机制。
session对象当客户端首次访问时，创建一个新的session对象。并同时生成一个sessionId，并在此次响应中将sessionId 以响应报文的方式返回客户端浏览器内存或以重写url方式送回客户端，来保持整个会话，只要sever端的这个session对象没有销毁，以后再调用 request.getSession()时就直接根据客户端的sessionId来检索server端生成的session对象并返回，不会再次去新 建，除非根据此sessionId没有检索到session对象。
下面是在IE下测试，因为IE 6.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())
// Has a Locale already been selected?
HttpSession session = request.getSession();
if (session.getAttribute(Globals.LOCALE_KEY) != null)
// 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。