A detailed configuration of the load process of Web. xml

One: Web. XML loading process

Simply put, the loading process of Web. Xml. When we launch a Web project container, the container includes (JBOSS,TOMCAT, etc.). First, the configuration in the Web. XML configuration file is read, and when this step is not faulted and completed, the project can be started normally.

When you start a Web project, the container first reads the two nodes in the XML config file:<listener> </listener> and <context-param> </context-param >

　　

Immediately thereafter, the container creates a ServletContext (application), and all parts of the Web project will share this context.　　The container takes the name of <context-param></context-param> as the key, and value is converted to a key-value pair and deposited ServletContext.

The container creates a class instance in <listener></listener>, creates a listener based on the configured class Classpath <listener-class>, and in the listening Initialize the method, when launching the Web app, the system calls the listener method contextinitialized (Servletcontextevent args), which is obtained in this method:

　　ServletContext application =servletcontextevent.getservletcontext ();

　　The value of Context-param = application.getinitparameter ("Key of Context-param ");

After you get the value of this context-param, you can do something about it.

For example: You may want to open the database before the project starts, so here you can set the database connection mode (driver,URL,user,password) in <context-param>. Initializes a connection to the database in the Listener class. This listener is a class of its own writing, in addition to the initialization method, it also has a method of destruction, to close the application before releasing resources. For example, when a database connection is closed, call contextdestroyed (Servletcontextevent args) to close the Web app, and the system calls the listener method.

　　The container then reads <filter></filter> and instantiates the filter according to the specified classpath.

These are the work that has already been done when the Web project is not fully up. If there is a servlet in the system , the servlet is instantiated the first time the request is initiated, and is generally not destroyed by the container, and it can serve the requests of multiple users. Therefore,the servlet is initialized much later than the ones mentioned above. Overall, theload order for Web. XML is : <context-param>-> <listener> <filter>-<servlet >. where the same element appears in Web. XML, it is loaded according to the order in which it appears in the configuration file.

II: Web. XML tag Details

1.<web-app></web-app>

<web-app></web-app> is the root element of the deployment description, which contains 23 child elements. In Servlet2.3, child elements must appear in the order specified in the DTD file description. For example: If the <web-app> element in the deployment descriptor has <servlet> and <servlet-mapping> two child elements, the <servlet> Child elements must appear before the <servlet-mapping> child element. In Servlet2.4, the order is not important.

2.<display-name></display-name>　

<display-name></display-name> defines the name of the Web App. such as <display-name>trk-order-rest</display-name>

3.<distributable/>

　　<distributable/> can use the distributable element to tell the servlet/jsp container thatthe application deployed in the Web container is suitable for running in a distributed environment.

4.<context-param></context-param>

　　

& The lt;context-param> element contains a pair of parameter names and parameter values that are used as the servlet context initialization parameters for the application, with the parameter names throughout web application, Arbitrary servlet and JSP can access it anytime, anywhere. <param-name> child elements contain parameter names, and <param-value> A child element contains a parameter value. As a choice, you can use <description> child elements to describe parameters.

configuration spring, must need <LISTENER> <context-param> Optional, if <context-param> configuration information is not written in web.xml, the default path is /web-inf/applicationcontext.xml, lang= >web-inf "en-us" created under applicationcontext.xml. If you want to customize the file name can be added in web.xml contextconfiglocation this Context parameter: Specify the corresponding xml file name in <param-value> if there are multiple xml files , which can be written together and separated by "business-client project, we adopted a custom configuration method, The <context-param> configuration is as follows:

　　

To configure multiple Web projects in the same container, it is best to define the Webapprootkey parameter in a different webapprootkey,web.xml file, and if not defined, the default is "Webapp.root", to prevent log4j configuration conflicts, Each project is configured with a different webapprootkey. As follows:

　　

Of course, you can not repeat, otherwise the report resembles the following error:

Web App root system property already set to different value: ' Webapp.root ' = [/home/user/tomcat/webapps/project1/] instead of [/home/user/tomcat/webapps/project2/]-Choose unique values for the ' Webapprootkey ' Context-param in your XML f iles!

5.<session-config></session-config>

　　

　　<session-config> sets the session parameters for the container , such as<session-timeout> for specifying The expiration time of the HTTP session. Default Time setting (30minutes). <session-timeout> is used to specify the default session time-out interval, in minutes. The element value is an integer. If the value of the session-timeout element is zero or negative, it means that the session will never time out.

6.<filter></filter> See my blog, here is not elaborated. (http://www.cnblogs.com/vanl/p/5742501.html)

　　

7.<listener></listener> See my blog, here is not elaborated. (http://www.cnblogs.com/vanl/p/5753722.html)

　　

8.<servlet></servlet>

8.1.Servlet Introduction

A servlet is often called a server-side applet and is a server-side program used to process and respond to customer requests. The servlet is a special Java class that creates a servlet class that automatically inherits HttpServlet. Clients typically have only get and post two requests, and Servlets must override the Doget () and Dopost () methods in response to both requests. Most of the time, the servlet is exactly the same for all request responses, at which point only the service () method is rewritten to respond to all requests from the client. In addition, there are two methods of HttpServlet:

Init (servletconfig config): When you create a servlet instance, call this method to initialize the servlet resource.

Destory (): Automatically calls this method to reclaim resources when the servlet instance is destroyed.

There is usually no need to rewrite the init () and Destory () two methods, unless you need to do some method of initializing the resources when initializing the servlet, consider overriding the Init () method. If you override the Init () method, you should call Super.init (config) on the first line of the method that overrides it, and the method will call the Init () method of HttpServlet. If you need to complete a collection of resources before destroying the servlet, such as closing the database link, you need to override the Destory () method.

Life cycle of 8.2.Servlet

There are two opportunities to create a servlet instance:

When a client requests a servlet for the first time, the system creates an instance of the servlet, most of which are the servlet;

A servlet instance is created as soon as the web app starts, i.e. <load-on-start>1</laod-on-start> (LZ has an article detailing: http://www.cnblogs.com/vanl/p/5756122.html)

Each servlet runs according to the following life cycle:

　　(1) Create a servlet instance.

(2) The Web container invokes the servlet's init () method to initialize the servlet.

(3) After the servlet is initialized, it will persist with the container in response to the client request, and if the client sends a GET request, the container calls the servlet's doget () method to process and respond to the request; If the client sends Post request, the container invokes the servlet's doPost () method to process and respond to the request. or uniformly use the service () method to respond to user requests.

(4)when the Web container decides to destroy the servlet, it first calls the servlet's destory () method, which typically destroys the servlet instance when the Web app is closed .

Configuration of 8.3.Servlet

In order for the servlet to respond to user requests, the servlet must also be configured in a Web app, and the servlet needs to be modified by the CONFIG. xml file. Starting with Servlet3.0, there are two ways to configure a servlet:

(1) Configuring in a servlet class using annotation-based methods: @WebServlet

(2) Configure in the Web. xml file.

　　

< Span lang= "en-US" > we use the web.xml file to configure servlet, need to configure <servlet> and <servlet-mapping>. <servlet> is used to declare a servlet. <icon>, <display-name> and <description> The use of elements is the same as <filter>. The <init-param> element has the same element descriptor as the <context-param> element and can be used <init-param> child elements pass the initialization parameter name and parameter value to servlet, Access The servlet configuration parameters are done through servletconfig objects, servletconfig provides the following methods:

　　Java.lang.String.getInitParameter (java.lang.String name): Used to get initialization parameters

ServletConfig get configuration parameters and ServletContext get configuration parameters exactly the same way, just Servletcontex is to get the configuration parameters of the current servlet, And ServletContext is the configuration parameter that gets the entire web app.

8.4. Configuring the servlet for spring MVC

　　

Configure spring MVC To specify the servlet to handle the request in two ways:

(1) The address of the default find MVC configuration file is:/web-inf/${servletname}-servlet.xml.

(2) You can specify the location of the MVC configuration file when configuring Dispatcherservlet by modifying the location of the configuration file.

We have used different configuration methods in two projects of platform project, which are described as follows:

We find the MVC configuration file by default in the Business-client project , the configuration file directory is: /web-inf/business-servlet.xml. The project directory structure is as follows:

　　

In the Public-base-server project, we configured in 2 ways to put the spring-servlet.xml in src/main/resources/config/ Spring-servlet.xml, you need to specify the <init-param> tag when configuring Dispatcherservlet . The specific code is as follows:

　　

The project directory structure is as follows:

　　

Where Classpath is the classpath of the Web project and can be understood as the classes directory. Because no matter where these configuration files are placed, there is no special case after compilation directly under classes. In our project, we have verified that the MAVEN project is the two

　　

The files generated by the path are all located in the classes directory, that is, the two paths are equivalent to the classpath, and the Config folder is created below to create a custom XML configuration file.

The difference between 8.5.classpath and classpath*

When a resource of the same name exists,classpath loads the resource only from the first qualifying classpath, and classpath* loads the eligible resource from all classpath. classpath*, the need to traverse all the classpath, efficiency is certainly not comparable to Classpath, so in the early stages of project design as far as possible to plan the path of resource files, avoid using classpath* to load.

8.6.ContextLoaderListener and Dispatcherservlet initialization context relationships and differences

　　

As can be seen, thecontextloaderlistener initialized context-loaded beans are shared for the entire application, generally such as:DAO layer,service layer bean; The Dispatcherservlet initialized context-loaded bean is a bean that is only valid for Spring MVC , such as:Controller,handlermapping, Handleradapter, the initialization context loads only the Web-related components.

Note: Users can configure multiple dispatcherservlet to handle different URL requests separately, each Dispatcherservlet context corresponds to a child spring container of its own . They all have the same parent Spring container (the container where the business layer, the Persistent (DAO)Bean resides).

9.<welcome-file-list></welcome-file-list>

　　

　　<welcome-file-list> contains a child element <welcome-file>,<welcome-file> is used to specify the name of the home page file. The <welcome-file-list> element can contain one or more <welcome-file> child elements. If the specified file is not found in the first <welcome-file> element, theWeb container tries to display the second one, and so on.

A detailed configuration of the load process of Web. xml