JSP implicit variables and the reading order of model in the El expression in spring

There is a certainty in chance, there is a chance

A bug that happens by chance, must exist by the code of unreasonable or even wrong

The longer the code logic, the more complex it is, the more prone to bugs

A few times before the project happened a bug, a simple description is the first time to add a B operation, and then add one, the page of an implied variable will "remember" the new ID, because it needs to be added twice in a row after the first new and after the B operation will not appear, So for a long time there were occasional occurrences.

The process of locating the problem is doing it many times and then eliminating it one by one. Try your own guesses and do the code-level exclusions again. It is necessary to have a certain amount of testing to locate this problem. It's like having an entrance and a maze of exits, the answer is the path to the occasional bug.

Finally, the problem was that the ID in the model was NULL, and the ID was stored in the session in the B operation.

Here's a look at the order of the El read variables

Background code

Package com.my.innerParam.test;

Import Javax.servlet.ServletConfig;
Import Javax.servlet.ServletContext;
Import Javax.servlet.http.HttpServletRequest;
Import Javax.servlet.http.HttpServletResponse;
Import javax.servlet.http.HttpSession;
Import Javax.servlet.jsp.JspWriter;
Import Javax.servlet.jsp.PageContext;

Import Org.springframework.stereotype.Controller;
Import Org.springframework.ui.Model;
Import org.springframework.web.bind.annotation.RequestMapping;

/**
* Test the order of several built-in variables in El Read
* @author Rocky
*
*/
@Controller
public class Innerparam
{
@RequestMapping ("/innerparamtest")
Public String innerparamtest (httpservletrequest request,httpservletresponse response,model Model)
{
HttpSession session = Request.getsession ();
Session.setattribute ("Session", "session223");

ServletContext application = Request.getservletcontext ();
Application.setinitparameter ("Appicationparam", "Appicationparam");
Initialization parameters can not is set after the context has been initialized
Application.setattribute ("Appicationattr", "applicationattr");
Request.setattribute ("Request", "request");


Model.addattribute ("Model", "model123");
return "/TESTPARAM/TESTPARAM1";
}

When a variable name is used to determine which of the El expressions to use
@RequestMapping ("/innerparamtest2")
Public String innerParamTest2 (httpservletrequest request,httpservletresponse response,model Model)
{
HttpSession session = Request.getsession ();
Session.setattribute ("Test", "session223");

ServletContext application = Request.getservletcontext ();
Application.setinitparameter ("Appicationparam", "Appicationparam");
Initialization parameters can not is set after the context has been initialized
Application.setattribute ("Test", "applicationattr");

Request.setattribute ("Test", "request");
Model.addattribute ("Test", "model123");
return "/TESTPARAM/TESTPARAM2";
}

When the model is NULL
@RequestMapping ("/innerparamtest3")
Public String innerParamTest3 (httpservletrequest request,httpservletresponse response,model Model)
{
HttpSession session = Request.getsession ();
Session.setattribute ("Test", "session223");

ServletContext application = Request.getservletcontext ();
Application.setinitparameter ("Appicationparam", "Appicationparam");
Initialization parameters can not is set after the context has been initialized
Application.setattribute ("Test", "applicationattr");

Request.setattribute ("Test", "request");
Model.addattribute ("test", null);
return "/TESTPARAM/TESTPARAM3";
}
}

In the first case, the display

Code

session:session223

Appicationattr: ' Applicationattr '

Appicationparam: "

Request: ' Request '

Model: ' model123 '

Second, the variable name is the same

Session:model123

Appicationattr: ' model123 '

Appicationparam: ' model123 '

Request: ' model123 '

Model: ' model123 '

Third, when model is null

 <  h3  >  session: ${test}</ h3  >  <  h3  >  appicationattr: ' ${test} ' 

 < H3 >model: ' ${test} '</h3> Run result

session:session223

Appicationattr: ' session223 '

Appicationparam: ' session223 '

Request: ' session223 '

Model: ' session223 '

Four, when the session is also null

<H3>Session: ${test}</H3><H3>Appicationattr: ' ${test} '</H3><H3>Appicationparam: ' ${test} '</H3><H3>Request: ' ${test} '</H3><H3>Model: ' ${test} '</H3>Run result session:applicationattrappicationattr: ' applicationattr ' appicationparam: ' applicationattr ' request: ' Applicationattr ' model: ' Applicationattr '

Conclusion: 1.model > Session >application>requset, the others are not tested, these are the longest use.

2. Use the session variable cautiously, this range is too large, if it is easier to implement the variable in the session because of a module, then it is easy to bury the bug in the back.

If you put the variable in the session, it means that it is scoped to the session , and its valid range is the current one. The so-called current session refers to the process of opening the browser from the user to the user closing the browser. This process may contain multiple request responses. In other words, as long as the user does not close the browser, the server has the means to know that these requests are initiated by a person, the entire process is called a session, and the variables placed in the session can be used in all requests of the current conversation. If you put the variable in the application, it means that its scope is application, and its effective range is the entire application. The entire application is launched from the app to the end of the app. We did not say "boot from server to server shutdown" because a server might deploy multiple applications, and of course you shut down the server and shut down all of the applications. Application The variables in the scope, they survive the longest, and if not manually deleted, they can be used all the time. Unlike the three above, the variables in the application can be shared by all users. If user A's operation modifies the variable in application, the User B gets the modified value when he accesses it. This will not happen in any other scope, page, request,

Refer to blog:jsp nine built-in objects and four scopes

3. Familiar with the JSP Foundation, already commonly used variables.

JSP implicit variables and the reading order of model in the El expression in spring