Servlet 3.0 Technical Documents
Author/Mao Yunwei [Issue Date: 2016/4/5]
In the development of JAVA EE Web, only JSP or Servlet can be used to present dynamic web pages, but the best way is to use the strengths of the two technologies: JSP is oriented towards web designers while Servlet is best for programmers. You can clarify the responsibilities between them to build your two teams with expertise that corresponds with the tools used while also reducing friction between the teams. In this article we discuss Servlet.
Basic Web Structure
A Web application basically consists of the following components:
- Static resources
- Custom classes
- Tools class
- Deployment description file - web.xml, setting information Annotation
Web applications are stored under the special directory /WEB-INF. The resource projects under this directory will not be included in the projects under the root directory that can be accessed directly, that is to say, the client (a browser for example) cannot directly request the resources under /WEB-INF (directly show clearly accessing /WEB-INF in the web site). The resource projects under /WEB-INF have certain names and structures.
- /WEB-INF/web.xml is a deployment description file.
- /WEB-INF/classes is used to place the custom classes used in an application and must include a package structure.
- /WEB-INF/lib is used to place the JAR file used in an application.
A web applications use a JAR file to hold Servlet, JSP, custom classes, tools class, deployment description files and the application's class loader will load the corresponding resources from this JAR file. The directory /META-INF/resources of the JAR file can be used to place static resources of JSP, for example, if a index.html is placed under /META-INF/resources and the requested URL includes /xxx/index.html, the /META-INF/resources/index.html in this JAR file will be used, because actually index.html does not exist under the directory /xxx /.
When a class is used, the web application will try to load this class from /WEB-INF/classes, and, if it cannot be found, then it tries to search for it from the JAR file under /WEB-INF/lib (if this class has not yet been found, the application will search for it from the directory where classes or JAR are stored, but the location varies from manufacture to manufacture).
The client cannot directly request resources in /WEB-INF, but the program can be made to retrieve resources from /WEB-INF through the control management on program surface, such as the getResource() and getResourceAsStream() of ServletContext, or request a calling by RequestDispatcher.
If a web application's URL ends with the character '/', and the directory exists, the web container must return the welcome page under this directory. You can include the following definitions in the deployment description file web.xml to point out the names of available welcome pages, and then the web container will check in order whether the corresponding files exist, and then, if the file exists, return it to the client:
Given the preceding example, if the web container is not able to find the file, it will try to search for the placed resource page in /META-INF/resources under the JAR file. If the URL ends with the character '/', and the directory does not exist, it will use Servlet by default (if there is a definition, refer to the instructions of the URL pattern).
Servlet 3.0 provides a new way (i.e., annotation) to manage the application's configuration settings. In Servlet 3.0, you choose one of the following ways to set Servlet, filters, and listeners for a web application.
1. Set configuration through the annotations of @WebServlet, @WebFilter, @WebListener;
2. Set configuration through web.xml. If the Servlet and filters set in the web.xml contain annotations, the settings in the web.xml are used as the main settings.
3. Set configuration through ServletContext's addServlet(), addFilter() and addListener() when the container is initialized. This can be implemented in ServletContextListener's contextInitialized() or in ServletContainerInitializer's onStartup().
If the META-INF/services/javax.servlet.ServletContainerInitializer file, a document file, exists in the JAR file, and the classes written in this document file are implemented javax.servlet.ServletContainerInitializer interface, these classes will be loaded and the onStartup() method will be executed.
In Servlet 3.0, you can use annotations to set Servlet's relevant information. The web container reads the annotation of the Servlet in /WEB-INF/classes and if the Servlet in the JAR file also use annotation the web also reads this Servlet's annotation, loads classes, and registers it with the service Servlet. However, the load order of Servlet, filters, listeners can be set only in web.xml and is the declaration order in web.xml (Servlet is in the case of same load-on-startup value). Servlet 3.0 supports the replacement of Servlet, filters and listeners. If the include files meet the requirements in the JAR file, you can achieve the replacement of the JAR file replaced, namely Servlet, filters and listeners. Actually, the JAR file in Servlet 3.0 can be used as a partial module of a Web application. The Servlet and the listeners and filters can be packaged in a JAR file after the defining annotations are written and then placed in a web application's /WEB-INF/lib on demand to increase or decrease the functionality of the web application.
The default value of metadata-complete's attribute in web.xml is false, but you can set it to true to indicate that the web application's relevant definitions in web.xml have been completed, therefore, the annotations and the definitions in web-fragment.xml will not be scanned during the deployment, and if any exist they'll be ignored. For example:
If the classes specified in web-fragment.xml can be found in the web application's /WEB-INF/classes, these classes will be used. What calls for attention is that, if a class itself has a label and meanwhile is definite as a Servlet in web-fragment.xml, there will be two instances. If the value of the metadata-complete's attribute is set to true (it's false by default), only the annotations in its JAR file will be handled.
The web container will assign a dedicated thread to be in charge of each arriving request and this thread will not be released to the container until the response is completed. A thread will consume system resources and some requests needing longer (such as prolonged operations or waiting for a resource) will occupy a thread for a longer time. If there are many such requests, many threads will be occupied for a long time and this will burden system effectiveness and result in application performance bottlenecks. For these requests take longer processing, if possible, you can make them release the threads assigned to them by the container, so that the container can allocate these threads to other requests to reduce the system's burden. Accordingly, the response to the request of the client who originally released threads will be delayed until the process is completed (e.g., finishing a prolonged operation, obtaining the required resources).
In Servlet 3.0, the method startAsync() is provided for ServletRequest.
The two methods will return the real objects of the AsyncContext interface. The former will directly use the original request to build AsyncContext with the response objects and the latter allows you to import requests built yourself and respond to packaged objects. After AsyncContext objects are obtained by calling startAsync(), the response will be delayed and the threads assigned by the container will be released. The two methods getRequest() and getResponse() are used to obtain requests and respond to objects, and the response to the client will be suspended to the time when AsyncContext's complete() or dispatch() is called, of which the former indicated that the response is completed and the latter indicated that it will be assigned to the specified URL to respond to the calling.
To be able to call startAsync of Servlet Request to use AsyncContext, your Servlet must be able to support asynchronous processing. If using @WebServlet to make a mark, you can set its asyncSupported to true. For example:
If use web.xml to set a filter, you can set the tag to true.
For incoming requests, Servlet will get its AsyncContext and then release threads assigned by the container, therefore, the response will be delayed. These requests with delayed responses will be discharged into a thread pool with a fixed treads number, so that these requests needing much time to process will be handled with a limited number of threads, without occupying the assigned threads for every request.