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