On nine built in objects and four scopes of jsp

  • 2021-11-13 08:37:59
  • OfStack

request Request Object Type javax. servlet. ServletRequest Scope Request

response Response Object Type javax. servlet. SrvletResponse Scope Page

pageContext page context object type javax. servlet. jsp. PageContext scope Page

session Session Object Type javax. servlet. http. HttpSession Scope Session

application Application Object Type javax. servlet. ServletContext Scope Application

out Output Object Type javax. servlet. jsp. JspWriter Scope Page

config configuration object type javax. servlet. ServletConfig scope Page

page Page Object Type javax. lang. Object Scope Page

exception Exception Object Type javax. lang. Throwable Scope page

The "exception" object represents the exception object generated when the JSP file is run. This object cannot be used directly in the JSP file, but can only be used when the " < %@ page isErrorPage="true "% > "Is used in the JSP file of the.

What is a scope

Let's look at the effect first:

The general process is as follows. When we visit index. jsp, we accumulate the variables in pageContext, request, session and application respectively. (Of course, first judge whether this variable exists or not, and if it does not exist, initialize the variable to 1). After the calculation is completed, perform forward jump from index. jsp to test. jsp. In test. jsp, add one more time, and then display these four integers.

From the displayed results, we can intuitively draw the conclusion:

Variables in page cannot be passed from index. jsp to test. jsp. As soon as the pages jump, they disappear.

Variables in request can span two pages before and after forward. But as soon as the page is refreshed, they are recalculated.

The variable 1 in session and application is accumulated directly, and there is no difference at first. As long as you close the browser and restart the browser to visit this page again, the variable in session will be recalculated.

The variable 1 in application is accumulating, and unless you restart tomcat, it will increase by 1.

Scope specifies the validity period of variables

If you put a variable in pageContext, it means that its scope is page, and its valid scope is only in the current jsp page.

You can use this variable from the time you put it in pageContext to the end of the jsp page.

If you put a variable in request, it is scoped to request and its valid range is the current request cycle.

The so-called request cycle refers to the whole process from the initiation of http request to the end of server processing and the return of response. In this process, you may jump to multiple jsp pages using forward, where you can use this variable.

If you put a variable in session, it means that its scope is session and its valid scope is the current session.

The so-called current session refers to the process from the user opening the browser to the user closing the browser. This process may contain multiple request responses. That is, as long as the user leaves the browser open, the server has a way to know that these requests are initiated by one person. The whole process is called one session (session), and the variables put in the session can be used in all requests of the current session.

If you put a variable in application, it means that its scope is application, and its effective scope is the whole application.

The whole application refers to from the start of the application to the end of the application. We didn't say "from server startup to server shutdown" because one server may deploy multiple applications. Of course, if you shut down the server, all the applications above will be shut down.

Variables in the application scope have the longest survival time, and if they are not manually deleted, they can be used directly.

Different from the above three, the variables in application can be shared by all users. If user A's operation modifies a variable in application, user B gets the modified value when accessing it. This will not happen in other scope, and page, request and session are completely isolated, so no modification will affect other people's data.


Related articles: