Tomcat configuration file web. xml and server. XML parsing-important

Document directory

• Servlet definition:
• Definition of servlet-mapping:
• Definition of session-config:
• Definition of mime-mapping:
• Finally, the definition of Welcom-file-list is as follows:
• Event listener:
• Filter:
• Filter Lifecycle
• First, the definition of server:
• Definition of listener:
• Definition of globalnamingresources:
• Service Definition:
• Definition of connector:
• Engine definition:
• Logger definition:
• Definition of realm:
• Host definition:
• Logger definition:

Main Content in Web. xml:

 

Servlet definition:

<Servlet>

<Servlet-Name> default </servlet-Name>

<Servlet-class>

Org. Apache. Catalina. servlets. DefaultServlet

</Servlet-class>

<Init-param>

<Param-Name> debug </param-Name>

<Param-value> 0 </param-value>

</Init-param>

<Init-param>

<Param-Name> listings </param-Name>

<Param-value> true </param-value>

</Init-param>

<Load-on-startup> 1 </load-on-startup>

</Servlet>

......

Definition of servlet-mapping:

<Servlet-mapping>

<Servlet-Name> default </servlet-Name>

<URL-pattern>/</url-pattern>

</Servlet-mapping>

 

<Servlet-mapping>

<Servlet-Name> JSP </servlet-Name>

<URL-pattern> *. jsp </url-pattern>

</Servlet-mapping>

 

<Servlet-mapping>

<Servlet-Name> JSP </servlet-Name>

<URL-pattern> *. jspx </url-pattern>

</Servlet-mapping>

 

Definition of session-config:

<Session-config>

<Session-Timeout> 30 </session-Timeout>

</Session-config>

 

Definition of mime-mapping:

<Mime-mapping>

<Extension> ABS </extension>

<Mime-type> audio/X-mPEG </mime-type>

</Mime-mapping>

 

Finally, the definition of Welcom-file-list is as follows:

<Welcome-file-List>

<Welcome-File> index.html </welcome-File>

<Welcome-File> index.htm </welcome-File>

<Welcome-File> index. jsp </welcome-File>

</Welcome-file-List>

 

There may be Event Listeners and filters.

Event listener:

Similar to servlet filters, event listeners are generated and initialized when a web application is deployed on a Web server.

Functions of listener types:

The servletcontext listener interface allows the Web to know the running status of the entire program, such as loading and unloading.

The httpsession listener interface allows the web program to understand the status of the program during the session and respond to it.

The servletrequest listener interface allows web programs to control the request lifecycle.

 

It is necessary to instantiate and register the listener class before the first request is accepted by the Web container. Listeners must be used throughout the web application lifecycle.

The Web Container creates only one instance (Singleton mode) for each listener class, instantiate and register the instance before the first request arrives. The order in which web containers register Listening Classes depends on the interfaces they implement and the order defined in the deployment description file. Web application call listening instances are registered in the order they are registered.

For appfuse, when the Web container is deployed according to the Application Deployment file web. XML, the instantiation and initialization of listener and filter are completed first.

Public ClassStartuplistenerExtendsContextloaderlistener

ImplementsServletcontextlistener {....

Startuplistener inherits from servletcontextlistener. Therefore, this listener is called when the container initializes servletcontext. The Web. xml of the appfuse application contains spring configuration information, so we have configured spring here !!!

 

Filter: Filter Lifecycle

After a web project is released, the engine must locate the Filter list before requesting the engine to access a web resource. The engine must ensure that an instance is created for each filter in the list, and called their Init (filterconfig config) method. In this process, an exception can be thrown. Deploy all filters defined in the description file. Only one instance is generated in the engine.

When the engine accepts a request, the engine will call the dofilter method of the first filter in the filter list, and pass servletrequest, servletresponse, and filterchain as parameters. The typical processing steps of the dofilter method in filter are as follows:

1) Check request header information

2) The developer creates a class that implements servletrequest or httpservletrequest and wraps the request object to modify the request header information or body data.

3) The developer creates a class that implements servletreqponse or httpservletresponse and wraps the response object to modify the request header information or body data.

4) A filter can call the next object in the chain. The next object is another filter. If the filter is the last one in the list, its next object is a target web resource. If you want to call the dofilter method of the next filter, send the request and response objects to the dofilter method of the filterchain object.

The dofilter method of the filter chain is provided by the engine. In this method, the engine locates the next filter in the filter list, calls its dofilter method, and passes the received request and response object to it.

5) after the chain. dofilter is called, the filter can detect the response header information.

6) in these processes, the filter can throw an exception. When an unavailableexception exception is thrown when dofilter is called, the engine attempts to handle it again.

The following filter chain method will close the filter chain request if the filter chain is not requested after expiration. When a filter is the last filter in the list, its next object is the servlet or other resources that describe the filter in the configuration file.

Before the engine deletes a filter, the engine must call the destroy method of the filter to release the resource.

 

Web. xml: All About applications.

 

<Web-app>

Various <context-param> ....

Various <filter> and <filter-mapping> ....

Various <listener> ....

Various <servlet> and <servlet-mapping>...

<Session-config>

<Welcome-file-List>

Various <error-page> ....

<Taglib>

<Resource-ref>

<Security-constraint>

<Login-config>

<Security-role>

 

The main content in server. XML is as follows:

<Server port = "8005" shutdown = "shutdown" DEBUG = "0">

...

Notes about server:

A "server" is a singleton element that represents the entire JVM,

Which may contain one or more "service" instances. The server

Listens for a shutdown command on the indicated port.

 

Definition of listener:

<Listener classname = "org. Apache. Catalina. mbeans. serverlifecyclelistener"

DEBUG = "0"/>

<Listener classname = "org. Apache. Catalina. mbeans. globalresourceslifecyclelistener"

DEBUG = "0"/>

 

Definition of globalnamingresources:

<Globalnamingresources>

 

<! -- Test entry for demonstration purposes -->

<Environment name = "simplevalue" type = "Java. Lang. Integer" value = "30"/>

 

<! -- Editable user database that can also be used

Userdatabaserealm to authenticate users -->

<Resource Name = "userdatabase" auth = "Container"

Type = "org. Apache. Catalina. userdatabase"

Description = "user database that can be updated and saved">

</Resource>

<Resourceparams name = "userdatabase">

<Parameter>

<Name> factory </Name>

<Value> org. Apache. Catalina. Users. memoryuserdatabasefactory </value>

</Parameter>

<Parameter>

<Name> pathname </Name>

<Value> CONF/tomcat-users.xml </value>

</Parameter>

</Resourceparams>

 

</Globalnamingresources>

 

Service Definition:

<Service name = "Catalina">

...

Note that connector and engine are both elements in the service.

 

Definition of connector:

<Connector Port = "8000" uriencoding = "GBK"

Maxthreads = "150" minsparethreads = "25" maxsparethreads = "75"

Enablelookups = "false" redirectport = "8443" acceptcount = "100"

DEBUG = "0" connectiontimeout = "20000"

Disableuploadtimeout = "true"/>

Comments about ctor:

A "connector" represents an endpoint by which requests are already ed

And responses are returned. Each connector passes requests on to

Associated "container" (normally an engine) for processing.

 

Engine definition:

<Engine name = "Catalina" defaulthost = "localhost" DEBUG = "0">

...

 

Engine comments:

An engine represents the entry point (within Catalina) that processes

Every request. The engine implementation for Tomcat stand alone

Analyzes the HTTP headers encoded with the request, and passes them

On to the appropriate host (virtual host ).

 

Logger definition:

<Logger classname = "org. Apache. Catalina. Logger. filelogger"

Prefix = "catalina_log." suffix = ". txt"

Timestamp = "true"/>

 

Definition of realm:

<Realm classname = "org. Apache. Catalina. realm. userdatabaserealm"

DEBUG = "0" resourcename = "userdatabase"/>

 

Host definition:

<Host name = "localhost" DEBUG = "0" appbase = "webapps"

Unpackwars = "true" autodeploy = "true"

Xmlvalidation = "false" xmlnamespaceaware = "false">

 

Logger definition:

<Logger classname = "org. Apache. Catalina. Logger. filelogger"

Directory = "logs" prefix = "localhost_log." suffix = ". txt"

Timestamp = "true"/>

Notes about logger:

Logger shared by all contexts related to this virtual host.

Default (when using filelogger), log files are created in the "logs"

Directory relative to $ catalina_home. If you wish, you can specify

A different directory with the "directory" attribute. specify either

Relative (to $ catalina_home) or absolute path to the desired

Directory.

 

... The definition of context may be later.

 

Server [Z1]. xml: it is about some server features.

A server has a service, and a service has multiple ctor ins and an engine. Different ctor INS may have different ports and protocols. Multiple ctor correspond to one engine. Engine represents the container of our application. One engine has one or more hosts, and one host represents one of our virtual hosts. There is one or more contexts in the host, and one context represents the virtual sub-site of an application.

 

There are also web. xml and struts-config.xml In the application, the content of these two configuration files is different from the configuration file that comes with Tomcat.

 

Tomcat application initialization and running process:

During Tomcat startup (initialization ):

Because applications are stored in the webapps directory, when Tomcat is started, its Web Container automatically verifies and loads the web programs in this directory so that they can work directly. If the program has an error, the web server outputs or stores the error information in the logs directory. if the error is serious, Tomcat may stop working.

 

From the above we can see that a webapp contains the following elements:

Filter, listener, servlet. The initialization time should be different.

 

Servlet and JSP lifecycle:

From Tomcat's processing of user requests, we can clearly see the lifecycle management process of the container servlet:

1. Tomcat should directly load and instantiate the listener and filter of the application under webapps at startup, and call them at the appropriate time.

2. The customer sends a request-> the Web server forwards the request to the Web Container tomcat;

3. the Tomcat main thread creates two objects in response to the requests forwarded by the user: httpservletrequest and httpservletresponse;

4. Find the correct servlet from the URL in the request. Tomcat creates or allocates a thread for it and passes the two objects created in 3 to the thread;

5. Tomcat calls the servlet servic () method and calls the doget () or dopost () method based on different request parameters;

6. For http get requests, the doget () method generates static pages and combines them into response objects;

7. When the servlet thread ends, Tomcat converts the response object to an HTTP Response and sends it back to the customer. The request and response object are also deleted.

In this process, we can understand the servlet lifecycle: servlet class loading (corresponding to step 4); servlet instantiation (corresponding to Step 3); calling the init method (corresponding to step 4 ); call the Service () method (corresponding to Steps 5 and 6); call the destroy () method (corresponding to Step 7 ).

From this, we can see that Servlet and JSP initialize servlet or JSP (converted to servlet) for the first time when the request arrives. After the initialization, only such an instance exists in the Web Container and multithreading is used to process requests from different users.

 

Struts-config.xml

<Form-beans>

Various <form-bean>

 

<Global-exceptions>

<Global-forwards>

Various <forward> ....

<Action-mappings>

Various <action> .... Action may also have a forward element. If yes, and it has the same name as the global-forwards element, it overwrites the global element.

 

Various </plug-in>