First, we will discuss how to create a session object in web development, generate sessionid, and return the running mechanism of the client.
When the client accesses the session object for the first time, a new session object is created. A sessionid is generated at the same time. In this response, the sessionid is returned to the client browser memory in response to the message or the URL is rewritten to the client to maintain the entire session, as long as the session object on the sever side is not destroyed, the request will be called later. when getsession () is used, the session object generated by the server is retrieved and returned Based on the sessionid of the client. The session object is not created again unless the session object is not retrieved Based on the sessionid.
The following is a test in IE, because a bug in ie6.0 is that even if the privacy settings of IE block all cookies, session cookies will be used to save the sessionid. so we will discuss the following in terms of session cookies,
(1) When the client requests the server servlet or JSP again within the time when the server is not closed and the session object is destroyed, the sessionid generated during the first request will be included in the request information header and sent to the server. After receiving the sessionid, the server will search for the sessionid accordingly (this process is transparent) the Session object corresponding to the server directly returns this session object. At this time, a new session object will not be created again.
(2) When the server is closed (the previously generated Session object disappears) or the session object expires, the browser window is closed, when you request the server Servlet and JSP in the browser window again, the sessionid (sessionid generated when the server is closed or the session is destroyed) will also be sent to the server, the server finds the corresponding session object based on the sessionid, but the session object does not exist at this time, and a new session object is generated, generate a new sessionid and send the newly generated sessionid to the browser memory as a response message.
(3) when the server is not closed and the session object is destroyed, when a JSP page is requested to return to the client, the browser window is closed, and the sessionid in its memory is destroyed, when you re-request the server servlet or JSP, a new sessionid is generated for the client browser, which is stored in the browser memory.
The above theory is true in servlet tests. Next, let's talk about the differences in the above tests under the Struts framework.
Let's briefly describe the procedure for testing the program:
The client requests index. Do --> to go to the server-side indexaction --> to the login. jsp page --> to request login. Do --> to enter the server-side loginaction.
First Note: No session object is generated in indexaction, and <% @ page session = "false" %> is set in login. jsp.
(1) Environment servlet + JSP:
In sevlet + JSP test trail. do changes to login after entering indexaction. in JSP, there is no session cookie in the browser memory. request login on JSP. after do enters loginaction, use request. during the getcookies () test, the value is null! The result is stable, because no session has been generated since the beginning!
(2) Environment STRUTS + JSP:
In the Struts + JSP test tracking, the results should be the same as the above process, but after debugging, the results are not as expected. In login. do is used after entering loginactoin, and request is used. during the getcookies () test, it was found that its value is not null, that is, its name and value are not understood at first, because no session object has been created. Where is the session cookie value. But the result is: the browser memory should also contain session cookies. The problem is here! Where did they come from?
After careful consideration, we thought of the characteristics of Struts. The action class we wrote was inherited from the action of struts, and was previously controlled by the central controller actionservlet of struts, so I think it must be before the program enters my own indexaction. The code in the Struts framework must have created the session object and generated the sessionid. so I found the relevant books and checked the actionservlet workflow and the classes to call. After reading it, I saw httpsession session = request. getsession! The answer is clear.
We all know that the struts actionservlet class receives requests from our client (*. do), instead of directly processing our request and calling the corresponding action (such as indexaction we wrote ), instead, the processing work is handed over to the requestprocessor class. The process method calls a series of methods to complete the corresponding request processing and redirection operations. One of the methods caught my attention, namely the processlocale () method.
Struts framework: the prototype of the processlocale () method in the requestprocess class is as follows:
Program code:
In Struts-config. the xml configuration file contains the corresponding configuration items: <controller locale = "true"> </controller> the default value of the locale attribute is true, and the processlocale method is called, the Session Object and sessionid are created in the first request. if it is set to false, the processlocale method will not be called after the first request reaches the actionservlet, and the session object will not be generated.
The result is displayed. In the struts application ,*. when do arrives at the server and passes through the actionservlet and turns to the indexaction we write, <controller locale = "true"> </controller> (default status, the Session Object and sessionid have been generated in the Struts framework class, even if we write httpsession session = request in indexaction. getsession (); it is also generated by the processlocale () method in the requestprocess class. In this case, the isnew of the session is still true, because the client has not been returned and it is newly created, then, according to the above process, when in login. through login. after do enters loginaction, its request. getcookies () are worth it! The value is generated when the processlocale () method in the requestprocess class generates the session object.
If we add <controller locale = "false"> </controller> In the struts-config.xml, then we track the program based on the above process and use request in loginaction. during the getcookies () test, the value is null. Of course, in indexaction, write httpsession session = request. getsession (); is newly created when it enters indexaction, and isnew is also 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 );
}
}