1. Configuration system management (Admin Web Application)
Most commercial J2EE servers provide a powerful management interface, and most use easy-to-understand Web application interfaces. In its own way, Tomcat also provides a mature management tool that is no less than its commercial competitors. Tomcat's Admin Web Application first appeared in version 4.1. Its functions at that time included managing context, data source, user and group, etc. Of course, you can also manage various database management such as initialization parameters, user, group, role, etc. In subsequent versions, these functions will be greatly expanded, but the existing functions are already very useful. Admin Web Application is defined in the automatic deployment file: CATALINA_BASE/webapps/admin.xml. (Translator's Note: CATALINA_BASE is the server directory under the tomcat installation directory)
You must edit this file to ensure that the docBase parameter in Context is an absolute path. In other words, the path of CATALINA
_BASE/webapps/admin.xml is an absolute path. As another option, you can also delete this automatic deployment file and create an Admin Web Application context in the server.xml file. The effect is the same. You cannot manage the Admin Web Application. In other words, you may not be able to do anything except 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 and add a role named "admin" to the file, as follows:
<role name="admin"/>
There also needs to be a user, and the role of this user is "admin". Add a user like an existing user (change the password to make it more secure):
<ser name="admin"
password="deep_dark_secret"
roles="admin"/>
After you complete these steps, please restart Tomcat and visit http://localhost:8080/admin . You will see a login interface. Admin Web Application adopts a security mechanism based on container management and adopts the Jakarta Struts framework. Once you log into the management interface as a user with the "admin" role, you will be able to configure Tomcat using this management interface.
2. Configure application management (Manager Web Application)
Manager Web Application allows you to perform some simple Web application tasks through a simpler user interface than Admin Web Application. The Manager Web Application is defined in an automatic 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 CATALINA_HOME/server/webapps/manager . (Translator's 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">
Also requires a user with the role "manager". Add a new user like an existing user (change the password to make it more secure):
<user name="manager"
password="deep_dark_secret"
roles="manager"/>
Then restart Tomcat, visit http://localhost/manager/list , you will see a very simple text management interface, or visit http://localhost/manager/html/list, you will see See an HMTL management interface. Either way, it means that your Manager Web Application has now been started.
The Manager application allows you to install new web applications for testing without system administration privileges. If we have a new web application located under /home/user/hello and want to install it under /hello, in order to test the application, we can do this and enter "/hello" in the first file box (As the path when accessing), enter "file:/home/user/hello" (as the Config URL) in the second text box.
The Manager application also allows you to stop, restart, remove and redeploy a web application. Stop an application so that it cannot be accessed. When a user tries to access the stopped application, he or she will see a 503 error - "503 - This application is not currently available".
Removing a web application simply means deleting the application from the running copy of Tomcat. If you restart Tomcat, the deleted application will reappear (that is, removal does not mean deleting it from the hard drive). ?
3. Deploy a web application
There are two ways to deploy web services in the system.
1. Copy your WAR file or your web application folder (including all the contents of the web) to the $CATALINA_BASE/webapps directory.
2. Create an XML fragment file for your web service that only includes context content, and place the file in the $CATALINA_BASE/webapps directory. The web application itself can be stored anywhere on your hard drive.
If you have a WAR file and you want to deploy it, you only need to simply copy the file to the CATALINA_BASE/webapps directory. The file must have ".war" as the extension. Once Tomcat listens for this file, it will (by default) unpack the file as a subdirectory and name the subdirectory the name of the WAR file.
Next, Tomcat will create a context in memory, just like you created it in the server.xml file. Of course, other required content will be obtained from the DefaultContext in server.xml.
Another way to deploy a web application is to write a Context XML snippet file and then copy the file to the CATALINA_BASE/webapps directory. A Context fragment is not a complete XML file, but just a context element and a corresponding description of the application.
This kind of fragment file is like the context element cut out from server.xml, so this kind of fragment is named "context fragment".
For example, if we want to deploy an application named MyWebApp.war that uses realm as an access control method, 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 characteristics, there is no need to restart Tomcat when installing a new web application.
4. Configure virtual hosts (Virtual Hosts)
Regarding the "Host" element in server.xml, you only need to modify it when you set up a virtual host. Virtual hosting is a mechanism for serving multiple domain names on a web server. For each domain name, it seems that the entire host is exclusive. In fact, most small business websites are implemented using virtual hosts. This is mainly because the virtual host can directly connect to the Internet and provide corresponding bandwidth to ensure a reasonable access response speed. In addition, the virtual host can also provide a stable fixed IP.
A name-based virtual host can be established on any web server by creating an alias of the IP address on the domain name server (DNS) and telling the web server to distribute requests for different domain names to the corresponding web directory. Because this article is mainly about Tomcat, we are not going to introduce the method of setting up DNS on various operating systems. If you need help in this regard, please refer to the book "DNS and Bind", written by Paul Albitz and Cricket Liu ( O'Reilly). For the sake of demonstration, I will use a static hosts file as this is the easiest way to test aliases.
To use virtual hosts in Tomcat, you need to set up DNS or host data. For testing, it is enough to set an IP alias for the local IP. Next, you need to add a few lines to 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="10" 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 -->
<Host name="localhost"
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 first
"Virtual Host": http://www.example.com/ -->
<Host name=" www.example.com "
appBase="/home/example/webapp">
<Context path="" docBase="."/>
</Host>
</Engine>
</Service>
</Server>
Tomcat's server.xml file, in its initial state, only includes one virtual host, but it can be easily expanded to support multiple virtual hosts. The previous example shows a simple version of server.xml, in which the bold part is used to add a virtual host. Each Host element must include one or more context elements, and one of the included context elements must be the default context. The display path of this default context should be empty (for example, path="").