Tomcat Usage Introduction __javaweb

Tomcat Overview

Tomcat is a good servlet container based on Sun's JSWDK (Javaserverweb Developmentkit, a small servlet/jsp debugging tool launched by Sun), Tomcat itself is written entirely in the Java language. Tomcat is a software project for the Apache Open source software organization. In addition to being able to act as a container for running the servlet, Tomcat also provides some of the usage features of a Web server, such as the Tomcat management and control platform. Security domain management and tomcat valves. Tomcat has been known as one of the best servlet container choices for developing enterprise Javaweb applications today. Tomcat as the basic function of the servlet container

A Servlet, as its name suggests, is a small plug-in that runs on a server. The most common use of the servlet is to extend the functionality of the Web server as a very safe, portable, and easy-to-use CGI substitute. The servlet has some features:

(1) provides the program code which can be dynamically loaded and executed by the server to provide the corresponding service from the customer's request.

(2) The servlet is written entirely in the Java language, so the server that requires the servlet to run must support the Java language.

(3) The servlet runs entirely on the server side, so its operation is not dependent on the browser. Regardless of whether the browser supports the Java language, you can request access to the server-side servlet.

As a container for running the servlet, Tomcat has the basic function of receiving and parsing requests from customers, sending customer requests to the appropriate servlet, and returning the servlet's response results to the customer.

The servlet specification stipulates that the Servlet container responds to customer requests for access to a particular servlet as follows:

(1) A request from a customer requesting access to a specially servlet.

(2) The servlet container has received a client request to parse it.

(3) The servlet container creates a ServletRequest object that contains the customer request information and other information about the customer, such as the request header, the request body, and the client's IP address, in the ServletRequest object.

(4) The servlet container creates a Servletresponse object.

(5) The servlet container invokes the service () services method of the servlet requested by the customer and passes the ServletRequest object and the Servletresponse object as parameters to the service method.

(6) The servlet can obtain the customer's request information from the ServletRequest object.

(7) The servlet uses the Servletresponse object to generate the response results.

(8) The servlet container sends the results of the servlet-generated response to the customer. setup for Tomcat

Download the corresponding version on the Tomcat website, the http://tomcat.apache.org/download page There are two ways to install the file, one is the executable file (32-bit/64-bit Windows Service Installer (PGP, MD5, SHA1)), one is a compressed file (64-bit Windows Zip (PGP, MD5, SHA1)). Executable files are usually said to install the version, compressed files is the hard disk installation version.

The installation process is relatively simple, and it is sometimes found that the configured JRE path errors are modified by opening the Tomcat installation directory/bin/tomcat7w.exe (7 in tomcat7w is the version number, the version is different, the number in the name of the file is different), A panel appears, and clicking "Java" in the panel appears with the Select button that selects the JRE path. You can choose again.

Installed Tomcat folder description under Installation path:

Folder name	Description
Bin	Tomcat's Start/stop control program
Conf	Configuration file
Lib	Storage directory for JAR packages
Logs	Startup log Storage Directory
WebApps	Web project file storage directory
Work	Working Time Directory

A detailed description of each directory will be covered below. the composition structure of Tomcat

Tomcat itself consists of a series of configurable components, where the core component is the servlet container component, which is the top-level container for all other Tomcat components. The following use <CATALINA_HOME> represents the installation root directory for Tomcat. The various components of Tomcat can be configured in the <catalina_home>/conf/server.xml file, and each Tomcat component corresponds to a configuration element in the Server.xml file. The following code shows the relationships among various Tomcat components in XML:

<Server>
         <Service>
                   <Connector/>
                   <Engine>
                            <Host>
                                     <context >
                                     </Context>
                            </Host>
                   </Engine>
         </Service>
</Server>

In the above code, each element represents a tomcat component, which can be grouped into the following 4 categories.

(1) Top-level class elements: including <Server> elements and <Service> elements, they are located at the top level of the entire configuration file.

(2) Connector class elements: for <Connector> elements, representing the communication interface between the client and the server, responsible for sending the client's request to the server and returning the server's response results to the customer.

(3) Container class element: Represents a component that handles customer requests and generates response results, with 4 container class elements, <Engine>, <Host>, <Context>, and <Cluster> elements, respectively. The engine component processes all customer requests for a specific service component, which handles all customer requests for a particular virtual host, and the context component processes all customer requests for a particular Web application. The cluster component is responsible for session replication for the Tomcat cluster system, replication of the attributes of the context component, and publication of the war file within the cluster scope.

(4) Nested class element: Represents a component that can be embedded in a container, such as a <Value> element and a <Realm> element. Publish Javaweb applications by default

The quickest way to publish a Javaweb application in Tomcat is to copy Javaweb to the Tomcat <catalina_home>/webapps directory directly with all the files that are used. By default, all Web applications in <catalina_home>/webapps run in a virtual host named "localhost", while the localhost virtual host runs in a engine component named "CATALINA."

Tomcat can run a Web application that uses an open directory structure, or it can run a packaged file for a Web application (the war file for short).

In the development phase of Web applications, an open directory structure is often used to publish Web applications for ease of debugging, which makes it easy to update or replace files. If the development is complete, enter the product release phase, the entire Web application should be packaged as a war file, and then published. Publish step:

(1) Packaging file generation can be used in the project Maven plug-in quickly and easily packaged, Project right > Debug mode (Debug as) >maven install, after the completion of the project in the Taeget directory on the right key >open Explore can see the already packaged Application war file (Webdemo1.0.0.war). You can also use the DOS command window: D:\workspace\webdemo>jar Cvfd:workspace\webdemo\webdemo.war *.*

(2) Rename the Webdemo1.0.0.war file to Webdemo.war and copy it to the <catalina_home>/webapps directory.

(3) If you have a WebApp subdirectory in the WebApps directory of Tomcat, delete the subdirectory first.

(4) Start the Tomcat server, open the page into the Application page, publish successfully.

When the Tomcat server starts, it automatically expands all war files in the WebApps directory into an open directory structure. Therefore, after the server is started, you will find that a Webdemo subdirectory is created in the WebApps directory and all content in Webdemo.war is expanded to the Webdemo subdirectory. Configure Tomcat's <Context> element publishing project

If you need to be more flexible in publishing Web applications, you need to configure Tomcat's <Context> elements for Web applications.

The <Context> element is the most frequently used element in Tomcat, which represents a single Web application running on the virtual host <Host>.

Primary properties of the context element

Specifies the file path for the Web application, either given an absolute path, or a relative path to the <Host> AppBase property. If the Web application uses an Open directory structure, specify the root directory of the Web application, or the path to the war file if the Web application is a war file.

tr> td>

Properties	description
Path	To specify the URL portal to access the Web application
DocBase
ClassName	Specifies the name of the Java class that implements the context component, and this Java class must implement the Org.apache.catali Na. The context interface. The default value for this property is Org.apache.catalina.core.StandardContext
reloadable	As This property is set to the TRUE,TOMCAT server will monitor changes to the class file in the Web-inf/calsses and Web-inf/lib directories and to monitor changes to the Web-inf/web.xml files for Web applications. If a class file or Web.xml file is detected, the server will automatically reload the Web application. The default value for this property is false. In the development and debugging stages of Web applications, setting Reloadable to True can facilitate debugging of Web applications. When the Web application is only released, setting reloadable to False can reduce the running load of Tomcat and improve the performance of Tomcat.

In general, the,<context> element uses the default standard context component, that is, the classname attribute takes the default value Org.apache.catalina.core.StandardContext. In addition to the attributes listed in the table above, the standard context has the following properties:

Property	Description
Cachingallowed	True indicates that caching of static resources is allowed to be enabled. Using caching can increase the efficiency of accessing static resources. Tomcat puts static resources (such as HTML documents, picture files, and sound files) that are often accessed by clients in the cache, and when the customer accesses the static resource again, Tomcat simply reads the relevant data from the cache without having to read the files in the file system repeatedly. The default value for this property is true.
Cachemaxsize	Sets the maximum size of the cache for a static resource, in K. For example, if this property is 100, the maximum cache size is 100K, or 100*1024 bytes. The default value for this property is 10240 (that is, 10M).
Workdir	Specifies the working directory for the Web application. Tomcat puts the temporary files associated with this Web application in this directory at run time.
Uppackwar	If this key is set to true, it means that the war file for the Web application is expanded to an open directory structure before it is run. If set to False, the war file is run directly. The default value for this property is true.

In the tomcat4.x version, configure <Context> elements directly in the <catalina_home>/conf/server.xml. There is a disadvantage to this configuration: If you modify the Server.xml file at Tomcat runtime, such as adding <Context> elements, the modifications will not take effect immediately, and you must restart Tomcat for the changes to take effect.

Tomcat6.x therefore does not advocate this approach, although it also allows <Context> elements to be configured in Server.xml files. Tomcat6.x provides a variety of ways to configure <Context> elements. When tomcat6.x loads a Web application, it tries to find the <Context> element of the Web application in turn, in the following V way, until it is found:

(1) Find <Context> elements in the <catalina_home>/conf/context.xml file. The information for <Context> elements in this file applies to all Web applications.

(2) Find <Context> elements in the <catalina_home>/conf/[enginename]/[hostname]/context.xml.default file. [Enginename] Represents the <Engine> Name property, and [hostname] represents the <Host> Name property. The information in the <Context> element in the Context.xml.default file applies to all Web applications in the current virtual host, such as the <Context> in the file element applies to all Web applications in the localhost host under the engine named Catalina:

<catalina_home>/conf/catalina/localhost/context.xml.default

(3) Find <Context> elements in the <catalina_home>/conf/[enginename]/[hostname]/[contextpath].xml file. [ContextPath] represents the URL entry for a single Web application. The <Context> element information in the [Contextpath].xml file applies only to a single Web application.

(4) Find <Context> elements in the Meta-inf/context.xml file of the Web application. The information for the <Context> elements in this file applies to the current Web application.

(5) Find <Context> child elements in the <Host> element in the <catalina_home>/conf/server.xml file. The information for this <Conteext> element applies only to a single Web application.

If you are only configuring <Context> elements for a single Web application, you can prioritize the third or fourth way. The third way requires adding a configuration file containing the <Context> element in the related directory of Tomcat, while the fourth requires adding a configuration file containing <Context> elements in the relevant directory of the Web application. In both ways, tomcat monitors the configuration file that contains <Context> elements is updated at run time, and if it is updated, Tomcat automatically reloads and launches the Web application so that changes to the <Context> elements take effect. Publishing multiple Web applications in Tomcat

Way one: The different Web application of the war file into the <catalina_home>/webapps directory, start the server can be accessed through the corresponding URL to different Web applications.

Mode Two: Configure multiple <Context> for the same <Host>

<context path= "/webdemo" docbase= "D:\WorkSpaces\StudyWorkSpace\eclipseWorkSpace\webdemo\src\main\webapp" Reloadable= "true"/>
<contextpath= "/demo docbase=" D:\WorkSpaces\StudyWorkSpace\eclipseWorkSpace\demo\ Src\main\webapp "reloadable=" true "/>

At this point, use the value of path path to differentiate the project:

Access the first item: http://localhost:8080/webdemo/index.jsp

Accessing the second item: http://localhost:8080/demo/index.jsp

The above two methods are the same, except that one is using the default publishing method, and the other is the way of configuration.

Mode Three: Configure multiple <service> in <catalina_home>/conf/server.xml, the default is only one <Service> element, copy the original <service> And after the original <Service></service> paste, paste the <connectorconnectiontimeout= "20000" port= "8080" protocol= "http/" The value of the port in the 1.1 "redirectport=" 8443/> element is changed to a different port. The modified Server.xml

<service name= "Catalina" > <connector connectiontimeout= "20000" port= "8080" protocol= "http/1.1" RedirectPort = "8443"/> <connector port= "8009" protocol= "ajp/1.3" redirectport= "8443"/> <engine defaultHost= "localhost "Name=" Catalina "> <realmclassname=" Org.apache.catalina.realm.LockOutRealm "> <realmclassname=" org.a Pache.catalina.realm.UserDatabaseRealm "resourcename=" Userdatabase "/> </Realm> The access paths to the two items after the modification are as follows:

http://localhost:8080/webdemo/index.jsp

http://localhost:8081/demo/index.jsp

But the above way seems to be only the port changes, the rest of the other can not see any difference. Looking closely at Tomcat's boot log, you can see that the third way the server starts to slow significantly slower than the first two. The Tomcat Management page (http://localhost:8080/manager/html and http://localhost:8080/manager/html) also shows that only the items in the corresponding service are included in each management module. Unlike the first two ways, you include all the items in a single management module.

The rest of the way can be attempted by following an introduction to the Server.xml document element. Try the result also hope message inform, learn from each other, in advance thanks. <catalina_home>/conf/server.xml Description

1. Configuring the server Element

The <Server> element represents the entire Catalinaservlet container, which is the top-level element of the Tomcat instance, defined by the Org.apache.catalina.Server interface. You can include one or more <Service> elements in a <Server> element, but <Server> elements cannot be child elements of any other element. The properties of the <Server> element are described in the following table:


 
 
 
  
 
   
 
    
Property
 
    
Description
 
   
 
   
 
    
ClassName
 
    
Specifies the class that implements the Org.apache.catalina.Server interface, with the default value of Org.apache.catalina.core.standardServer
 
   
 
   
 
    
Port
 
    
Specifies the port on which the Tomcat server listens for shutdown commands. When the Tomcat server is terminated, the shutdown command must be issued on the machine on which the Tomcat server is located, and this attribute must be set.
 
   
 
   
 
    
Shutdown
 
    
Specifies the string that will be sent to the Tomcat server's shutdown listening port when the Tomcat server is running, and this attribute must be set.
 
   
 
  
 

 
 
2. Configure Service elements

The <Service> element is defined by the Org.apache.catalina.Server interface, which contains a <Engine> element, and one or more <Connector> elements, these < The connector> element shares the same <Engine> element. For example, two <Service> elements are configured in the Server.xml file:

<servicename= "Catalina" >

<servicename= "Apache" >

The first <Service> handles all Web client requests that are received directly from the Tomcat server, and the second <Service> handles web client requests forwarded by the Apache server.

The properties of the <Service> element are described below:

ClassName: Specifies the class that implements the Org.apache.catalina.Service interface, and the default value is Org.apache.catalina.core.StandardService.

Name: Defines the service names.

3. Configure engine elements

<Engine> elements are defined by the Org.apache.catalina.Engine interface. Each <Service> element can contain only one <Engine> element,<engine> element that handles client requests received by all <Connector> elements in the same <Service>. Properties of the <Engine> element:

ClassName: Specifies the class that implements the Org.apache.catalina.Engine interface, and the default value is Org.apache.catalina.core.StandardEngine.

Defaulthost: Specifies the default host name for processing customer requests, which must be defined in <Host> child elements of <Engine>

Name: Defines the names of engine

You can also include <Realm>, <Value>, and <Host> child elements in the <Engine> element.

4. Configure the Host element

<Host> elements are defined by the Org.apache.catalina.Host interface. A <Engine> element can contain multiple <Host> elements, and each <Host> element defines a virtual host that can contain one or more Web applications. The properties of the <Host> element are described below:


 
 
 
  
 
   
 
    
Property
 
    
Description
 
   
 
   
 
    
ClassName
 
    
Specifies the class that implements the Org.apache.catalina.Host interface, with the default value of Org.apache.catalina.core.standardHost
 
   
 
   
 
    
AppBase
 
    
Specifies the directory for the virtual host, either by specifying an absolute directory or by specifying a relative directory relative to the <CATALINA_HOME>. If this item is not set, the default value is <catalina_home>/webapps
 
   
 
   
 
    
Unpackwars
 
    
If this key is set to True, the Web application's war file will be expanded to an open directory structure before running. If set to False, the war file is run directly.
 
   
 
   
 
    
Autodeploy
 
    
If this key is set to true, it means that when the Tomcat server is running, it is able to monitor the files under AppBase and will automatically publish the Web application if a new Web application is added.
 
   
 
   
 
    
Alias
 
    
Specifies the alias of the virtual host, and you can specify multiple aliases.
 
   
 
   
 
    
Deployonstartup
 
    
If this key is set to True, all Web applications under the AppBase directory are automatically published when the Tomcat server is started, and if the Web application does not respond to <Context> elements in Server.xml, The tomcat default context will be adopted. The default value is true.
 
   
 
   
 
    
Name
 
    
Define the name of the virtual host.
 
   
 
  

 
 
5. Configure the context element

<Context> elements are defined by the Org.apache.catalina.Context interface. <Context> elements are the most frequently used elements, each <Context> element represents a single Web application running on a virtual host, and a <Host> element can contain multiple <Context> elements. The properties of the <Context> element are described in the following table:


 
 
 
  
 
   
 
    
Property
 
    
Description
 
   
 
   
 
    
ClassName
 
    
Specifies the class that implements the Org.apache.catalina.Context interface, and the default value is Org.apache.catalina.core.standardContext.
 
   
 
   
 
    
Path
 
    
Specify the URL portal to access the Web application
 
   
 
   
 
    
DocBase
 
    
Specifies the file path for the Web application, given an absolute path, or a relative path relative to the host's AppBase property. If the Web application uses an Open directory structure, specify the root directory of the Web application; If the Web application is a war file, specify the path to the war file
 
   
 
   
 
    
Reloadable
 
    
If this property is set to True, the Tomcat server will monitor changes to the class file in the Web-inf/classes and Web-inf/lib directories and to monitor changes to the Web-inf/web.xml file for Web applications in the running state. If a class file or Web.xml file is detected, the server will automatically reload the Web application. The default value for this property is false. In the development and debugging of Web applications, setting this property to true can facilitate the debugging of Web applications. In the formal publishing phase of Web applications, setting this property to False can reduce the running load of Tomcat and improve the performance of Tomcat.
 
   
 
   
 
    
Cookies
 
    
Specifies whether the session is supported by a cookie, and the default value is True
 
   
 
   
 
    
Usenaming
 
    
Specifies whether Jndi is supported, and the default value is True
 
   
 
  

 
 
You can include <Realm>, <Value>, and <Resource> elements in the <Context> element.

6. Configure connector elements

<Connector> elements are defined by the Org.apache.catalina.Connector interface. The <Connector> element represents the component that actually interacts with the client program, which is responsible for receiving customer requests and returning response results to the customer.

For example:

<connector port= "8080" protocol= "http/1.1" connectiontimeout= "20000" redirectport= "8443"/>

<connector port= "8009" protocol= "ajp/1.3" redirectport= "8443"/>

The first <Connector> element defines an HTTP Connector that receives HTTP requests via port 8080, and the second <Connector> element defines a AJP Connector, It receives a client request forwarded by another HTTP server over 8009 ports. <Connector> element Properties:


 
 
 
  
 
   
 
    
Property
 
    
Description
 
   
 
   
 
    
Enablelookups
 
    
If set to true to support domain name resolution, IP addresses can be resolved to host names. Calling the Request.getremosthost method in a Web application returns the client's host name with the default value of True
 
   
 
   
 
    
Redirectport
 
    
Specifies the port of transfer. If the front-end port supports only NON-SSL requests, the property will forward the client request to the SSL-based Redirectport port in the event that a secure communication is required
 
   
 
  
 

 
 
Properties of HTTP connector elements


 
     The 
    
 
 
  
 
   
 
    
Property
 
    
Description
 
   
 
   
 
    
Enablelookups
 
    
If set to true to support domain name resolution, IP addresses can be resolved to host names. Calling the Request.getremosthost method in a Web application returns the client's host name with the default value of True
 
   
 
   
 
    
Redirectport
 
    
Specifies the port of transfer. If the front-end port supports only NON-SSL requests, the property will forward the client request to the SSL-based Redirectport port in the event that a secure communication is required
 
   
 
   
 
    
Port
 
    
Set TCP/IP port number, default value is 8080
 
   
 
   
 
    
Address
 
    
If the server has more than two IP addresses, this property can set the IP address that the port listens on, by default, the port will ship all the IP addresses on the server.
 
   
 
   
 
    
BufferSize
 
    
Sets the cache size of the input stream that is critical by the port difference un, with a default value of 2048 bytes
 
   
 
   
 
    
Protocol
 
    
Set HTTP protocol
 
   
 
   
 
    
MaxThreads
 
    
Sets the maximum number of threads to process client requests, which also determines the maximum number of simultaneous client requests that the server can respond to, with a default value of 40
 
   
 
   
 
    
Acceptcount
 
    
Sets the maximum number of client requests in the listening port queue, with a default value of 10. If the queue is full, the client request will be rejected
 
   
 
   
 
 ConnectionTimeout 
 
 
    
 
 Defines the time, in milliseconds, to establish a client connection timeout. If set to-1, the time to establish a client connection is not limited, with a default value of 60000 milliseconds, or 60 seconds