Servlet 2.4 specification Article 4: Servlet context

SRV.3.1 ServletContext Interface Description

The ServletContext interface defines servlet-related view information in the web application running servlet. The container provider is responsible for providing a specific set of implementations of ServletContext. Through the ServletContext object, servlet can record events, obtain resource references, and set and save some attributes of other servlets on the current context.

ServletContext uses a path of a web application as the root node. For example, the servlet context can be written as http://www.mycorp.com/catalog. All requests starting from the/catalog path, that is, the context path, are routed to the web application associated with this ServletContext.

SRV.3.2 scope of the ServletContext Interface

Each web application deployed in the container has a corresponding ServletContext instance. If the container is distributed in multiple virtual machines, the web application has a ServletContext instance for each JVM.

Servlets that are not deployed as part of a web application are divided into default web applications, and there is also a default ServletContext. In distributed containers, the default ServletContext is not used for distributed processing. It can only be stored in one JVM.

SRV.3.3 initialization parameters

The following method of the ServletContext interface allows the servlet to access the initialization parameters of the context. Of course, these parameters are specified by the application developer in the deployment descriptor.

• GetInitParameter
• GetInitParameterNames

Initialization parameters are mainly used to pass information about some setting classes. A typical example is to set the email address of the web administrator or the name of the Threshold Control System.

SRV.3.4 Context attributes

Servlet can bind some property objects through name-value pairs. Any attributes bound to the context can be accessed by other servlets under the same web application. The following four methods of the ServletContext interface allow access to these functions:

• SetAttribute
• GetAttribute
• GetAttributeNames
• RemoveAttribute

SRV.3.4.1 Context attribute in Distributed containers

The Context attribute is located at the creation of their JVM, so that the ServletContext attribute is not used in the shared memory mode of distributed containers. When the servlet running in a distributed environment needs to share data, the data should be stored in the session, stored in the database, or in the EJB component.

SRV.3.5 Resource

The ServletContext interface provides the ability to access static content in a web application, including HTML, GIF, and JPEG files. The corresponding method is described as follows:

• GetResource
• GetResourceAsStream

The getResource and getResourceAsStream methods receive strings guided by the forward slash "/" as parameters. This parameter specifies that the corresponding resources are searched from the context root directory, the file to be found must exist in the file system of the server, war package, remote server, or other locations.

These two methods cannot be used to access dynamic content. For example, when getResource ("/index. jsp ") will return the source code of the jsp page, rather than the normal execution result of the expected jsp page.

The list of all resources that can be accessed through getResourcePaths (String path) in web applications, and all syntax details of this method can be found in the API documentation of this specification.

SRV.3.6 multi-host and servlet context

The web service system may support multiple logical hosts on one server to share one IP address. This capability is also called a virtual host. In this case, each logic host must maintain its own servlet context or servlet contexts. Servlet contexts cannot be shared by multiple virtual hosts.

SRV.3.7 thoughts on heavy load

Container developers do not have to implement the class overload mechanism. However, once implemented, make sure that all servlets and classes are successfully loaded within the same class loader range. This requirement is to ensure that the application is executed as intended by application developers. It is recommended that developers support all listeners bound to the session to obtain the notification information for session termination and reload, and handle the session appropriately.

The previous generation container creates a new class loader and loads servlet, which is different from loading other servlet or class files in the servlet context. This misunderstanding error may cause a reference in the servlet context to point to an unexpected class or object and cause unpredictable behavior.

SRV.3.7.1 temporary working directory

A temporary storage directory is required for each servlet context. The servlet container must provide a separate private temporary directory for each servlet context and make it accessible through the context attribute javax. servlet. context. tempdir. The object corresponding to this attribute must be of the java. io. File type.

This requirement is common and convenient in many servlet engines. When the servlet container restarts, it does not need to maintain the content in the temporary working directory, but must ensure that the content of the temporary working directory in a servlet context is completely invisible to other running servlet contexts.

 

Document Information

• Translator: Uncle Zhang
• Http://www.cnblogs.com/flance/
• Copyright statement: Free Reprint-non commercial-Non derivative-keep the signature | Creative Commons BY-NC-ND 3.0