Tomcat Configuration Tips Top 10 Rankings

Skills

1, configuration system Management (Admin WEB application)

Most commercial Java EE servers provide a powerful management interface, and most of them use an Easy-to-understand Web application interface. Tomcat, in its own way, also provides a sophisticated management tool that is no less competitive than those of a commercial competitor. Tomcat's admin Web application originally appeared in version 4.1, with functions such as admin context, data source, user, and group. Of course can also manage like initialization parameters, user, group, role of a variety of database management. In subsequent releases, these features will be greatly expanded, but the existing functionality is already very useful. The Admin WEB application is defined in the automatic deployment file: Catalina_base/webapps/admin.xml. (Translator Note: Catalina_base is the server directory under the Tomcat installation directory)

You must edit this file to determine that the Docbase parameter in the context is an absolute path. In other words, CATALINA

The _base/webapps/admin.xml path is an absolute path. As an alternative, you can also delete the automatic deployment file, and in the Server.xml file to create a admin Web application context, the effect is the same. You can't manage the admin Web application This application, in other words, you may not be able to do anything other than delete Catalina_base/webapps/admin.xml.

If you use Userdatabaserealm (default), you will need to add a user and a role to the Catalina_base/conf/tomcat-users.xml file. You edit this file, add a role called "admin" to the file, as follows:

<role name= "admin"/>

Also need to have a user, and this user's role is "admin". Add a user (change the password to make it more secure), as in the case of existing users:

<ser name= "Admin"
Password= "Deep_dark_secret"
roles= "Admin"/>

After you complete these steps, please restart Tomcat, visit Http://localhost:8080/admin, and you will see a login interface. The Admin WEB application uses a container-managed security mechanism and employs the Jakarta struts framework. Once you are logged in as the Admin user Login Admin interface, you will be able to configure Tomcat using this admin interface.

2. Configure Application Management (Manager Web application)

The Manager Web application lets you perform some simple Web application tasks through a simpler user interface than the admin Web application. The Manager WEB application is defined in an automated deployment file:

Catalina_base/webapps/manager.xml

You must edit this file to ensure that the Docbase parameter of the context is an absolute path, that is, the absolute path of the Catalina_home/server/webapps/manager. (Translator Note: Catalina_home is the Tomcat installation directory)

If you are using Userdatabaserealm, then you need to add a role and a user to the Catalina_base/conf/tomcat-users.xml file. Next, edit the file and add a role named "Manager" to the file:

<role name= "Manager" >

There is also a need for a user with a role of "manager". Add a new user (change password to make it more secure), as already existing users:

<user name= "Manager"
Password= "Deep_dark_secret"
roles= "Manager"/>

Then restart Tomcat, visit http://localhost/manager/list, see a very simple text-management interface, or visit http://localhost/manager/html/list, You will see a HMTL management interface. Either way, it means your manager Web application is now started.

Manager application allows you to install new Web applications for testing without system administration privileges. If we have a new Web application under/home/user/hello and want to install it under/hello, in order to test this application, we can do this, in the first file box, enter "/hello" (as Path to visit), and in the second text box, type " File:/home/user/hello "(as config URL).

Manager application also allows you to stop, reboot, remove, and redeploy a Web application. Stop an application so it can't be accessed, and when a user tries to access this stopped application, you see a 503 error??? 503-this application is not currently available ".

Removing a Web application means that the application is removed from Tomcat's running copy, and if you restart Tomcat, the deleted application will reappear (that is, removal is not meant to be removed from the hard drive).

3. Deploy a Web application

There are two ways to deploy Web services in your system.

1. Copy your war file or your Web application folder (including all the content of the Web) into the $catalina_base/webapps directory.

2. Create an XML fragment file that includes only the context content for your Web service and place the file in the $catalina_base/webapps directory. The Web application itself can be stored anywhere on the hard disk.

If you have a war file, if you want to deploy it, simply copy the file to the Catalina_base/webapps directory, and the file must be extended with ". War". Once Tomcat hears this file, it unlocks the package (by default) as a subdirectory and takes the name of the war file as the subdirectory.

Next, Tomcat creates a context in memory as if you were building it in a server.xml file. Of course, other necessary content will be obtained from the Defaultcontext in Server.xml.

Another way to deploy a Web application is to write a context XML fragment file and then copy the file to the Catalina_base/webapps directory. A context fragment is not a complete XML file, but a context element, as well as a corresponding description of the application.

This fragment file is like a context element that is cut from the server.xml, so this fragment is named "Context fragment."

For example, if we want to deploy an application called Mywebapp.war, the application uses realm as an access control, we can use the following fragment:

<!--
Context fragment for deploying Mywebapp.war
-->
<context path= "/demo"
Docbase= "Webapps/mywebapp.war"
debug= "0" privileged= "true" >
<realm classname=
"Org.apache.catalina.realm.UserDatabaseRealm"
Resourcename= "Userdatabase"/>
</Context>

Name the fragment "Mywebapp.xml" and copy it to the Catalina_base/webapps directory.

This context fragment provides a convenient way to deploy Web applications, you do not need to edit server.xml, unless you want to change the default deployment features, you do not need to restart Tomcat to install a new Web application.

4. Configure Virtual Host

About the "host" element in Server.xml, only if you set up a virtual host, you need to modify it. A virtual host is a mechanism that serves multiple domain names on a Web server, and for each domain name it seems to have exclusive access to the entire host. In fact, most small business Web sites are implemented using a virtual host, mainly because the virtual host can directly connect to the Internet and provide the appropriate bandwidth to ensure a reasonable access response speed, another virtual host can provide a stable fixed IP.

A name-based virtual host can be built on any Web server by creating an alias for the IP address on the domain name server (DNS) and telling the Web server to distribute requests to different domain names to the corresponding Web page directory. Since this article is mainly about Tomcat, we're not going to introduce a way to set up DNS on a variety of operating systems, and if you need help with this, refer to DNS and Bind, the author of Paul Albitz and Cricket Liu (O ' Reilly). For demonstration convenience, I will use a static host file, because this is the easiest way to test the alias.

Using a virtual host in Tomcat, you need to set up DNS or host data. To test, setting an IP alias for a local IP is sufficient, and then you need to add a few lines to the Server.xml, as follows:

<server port= "8005"
shutdown= "shutdown" debug= "0" >
<service name= "Tomcat-standalone" >
<connector classname=
"Org.apache.coyote.tomcat4.CoyoteConnector"
port= "8080"
minprocessors= "5" maxprocessors= "75"
Enablelookups= "true"
redirectport= "8443"/>
<connector classname=
"Org.apache.coyote.tomcat4.CoyoteConnector"
Port= "8443" minprocessors= "5"
maxprocessors= "75"
Acceptcount= "Ten" debug= "0"
Scheme= "https" secure= "true"/>
<factory classname= "Org.apache.coyote.
Tomcat4. Coyoteserversocketfactory "
Clientauth= "false" protocol= "TLS"/>
</Connector>
<engine name= "Standalone"
defaulthost= "localhost" debug= "0" >
<!--This host is the default host-->
debug= "0" appbase= "WebApps"
Unpackwars= "true" autodeploy= "true" >
<context path= "" docbase= "ROOT" debug= "0"/>
<context path= "/orders"
Docbase= "/home/ian/orders" debug= "0"
Reloadable= "true" crosscontext= "true" >
</Context>
</Host>

<!--this Host is the
"Virtual Host": http://www.example.com/-->
appbase= "/home/example/webapp" >
<context path= "" docbase= "." />
</Host>

</Engine>
</Service>
</Server>

Tomcat's Server.xml file, in its initial state, includes only one virtual host, but it is easily extended to support multiple virtual hosts. In the previous example, a simple Server.xml version was shown, where the bold part was used to add a virtual host. Each host element must include one or more context elements, one of which must be the default, and the display path for this default will be empty (for example, path= "").