Session object creation and control in the Struts framework

First, we'll talk about the creation of the session object in Web development and the SessionID to generate and return the client's running mechanism.

Session object when the client first accesses, create a new sessions object. And generate a SessionID at the same time, and in this response SessionID in response to the message back to the client browser memory or to the client to rewrite the URL to maintain the entire conversation, As long as the sever end of this session object is not destroyed, and then call Request.getsession () directly based on the client's SessionID to retrieve the server-side generated session object and return, do not go to new, The session object is not retrieved unless it is based on this sessionid.

The following is a test in IE, because a bug in IE6.0 is that IE's privacy settings save the SessionID as a session cookie even when all cookies are blocked. So the following are discussed as session cookies,

(1) When the server is not shut down and the session object is destroyed, when the client requests the server-side servlet or JSP again, the SessionID generated on the first request will be sent to the server side with the requested header, When the server side receives the SessionID, the SessionID searches for (this process is transparent) the corresponding session object of the server and returns directly to the session object, and does not re-establish a new session object.

(2) When the server is closed (before the resulting session object is also extinct), or the session object after its destruction time, the browser window is not closed, and in this browser window again to request the sever side of the servlet and JSP, the same time will be SessionID ( The server shuts down or the SessionID generated when session is destroyed) is sent to the server side, and the server according to SessionID to find its corresponding session object, but the session object no longer exists. A new Session object is regenerated and a new SessionID is generated and the newly generated SessionID is also sent to the browser in the form of a response message.

(3) When the server is not closed, and the session object in its destruction time, when requesting a JSP page back to the client, close this browser window, at this time its memory in the SessionID also destroyed, in the request sever side of the servlet or JSP, A SessionID is regenerated to the client browser and exists in browse memory.

The above theory is set up in the servlet test, and here's a look at the different parts of the test in the struts framework.

Let's briefly say the process of testing the program:

Client Request Index.do---> enter server indexaction---> Turn to login.jsp page-----> Request login.do-----> into server side loginaction .

First Note: Indexaction not to generate session object, login.jsp set.

(1) Environment servlet + JSP:

When sevlet+jsp a test trace, when index.do into the indexaction and then turn to login.jsp, there is no session cookie in the browser memory. Then when the login.do is requested to enter the Loginaction on the login.jsp, the value of the request.getcookies () test is NULL! The result is stable, because from the beginning of the end has not produced session!

(2) Environment struts + JSP:

In struts+jsp test tracking, as with the above process, the beginning to think the results should be the same, but after debugging found that the results are not what they think. After login.do into Loginactoin, use Request.getcookies () to test, The discovery that its value is not NULL, that is, its name and value, is beginning to be incomprehensible, since there is no session cookie value created at all. But the result is that there should be a session cookie in the browser's memory at this point! Where did it come from? ?

After careful consideration, thinking about the characteristics of struts, our own action class is inherited from struts action, and it was previously controlled by the central controller Actionservlet of struts. So I'm sure it was before the program entered my own indexaction, The code in the struts framework must have created the session object and already generated the SessionID. So I found the relevant books to see the Actionservlet workflow and what classes to call, and after looking at it, I saw the HttpSession Session = Request.getsession (); So the answer is clear.

You know that struts in the Actionservlet class after receiving our client's request (*.do) (Will do a series of initial chemical work), not directly to deal with our request and invoke the corresponding action (we write such as Indexaction), Instead, the processing work is given to the Requestprocessor class, and a series of methods are invoked in the process method to complete the corresponding request processing and steering operations. One of the ways that I'm concerned about is the Processlocale () method.