Shulou(Shulou.com)06/02 Report--

This article is about how to configure Tomcat in Java. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

1. Configure system Management (Admin Web Application)

Most commercial J2EE servers provide a powerful management interface, and most of them use Web application interface that is easy to understand. Tomcat also provides a mature management tool in its own way, and is no less inferior to its commercial competitors. Tomcat's Admin Web Application first appeared in version 4.1, when functions included managing context, data source, user, and group. Of course, you can also manage multiple database management such as initialization parameters, user, group, role, and so on. In subsequent releases, these features will be greatly extended, but the existing features 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 make sure that the docBase parameter in Context is the absolute path. In other words, CATALINA

The path to _ BASE/webapps/admin.xml is absolute. As an alternative, you can also delete the auto-deployment file and create an Admin Web Application context in the server.xml file with the same effect. You can't manage the Admin Web Application app, in other words, you may not be able to do anything but delete CATALINA_BASE/webapps/admin.xml.

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

You also need to have a user, and the user's role is "admin". Like an existing user, add a user (change the password to make it more secure):

After you have completed these steps, restart Tomcat, visit http://localhost:8080/admin, and you will see a login screen. Admin Web Application adopts the security mechanism based on container management and adopts the Jakarta Struts framework. Once you log in to the admin interface as a user of the "admin" role, you will be able to configure Tomcat using this admin 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. Manager Web Application is defined in an automatic deployment file:

CATALINA_BASE/webapps/manager.xml

You must edit this file to make sure that the docBase parameter of context is the 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, 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:

You also need to have a user with the role "manager". Like an existing user, add a new user (change the password to make it more secure):

Then restart Tomcat, visit http://localhost/manager/list, and you'll see a very simple text-based management interface, or visit http://localhost/manager/html/list, and you'll see an HMTL management interface. Either way, it means that your Manager Web Application is now on.

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, to test the application, type "/ hello" (as path for access) in the first file box and "file:/home/user/hello" (as Config URL) in the second text box.

Manager application also allows you to stop, restart, remove, and redeploy a web application. Stop an application to make it inaccessible, and when a user tries to access the stopped application, they will see a 503 error. "503-This application is not currently available".

Removing a web application simply means removing the application from the running copy of Tomcat, and if you restart Tomcat, the deleted application will reappear (that is, removal does not mean removal from the hard drive).

Deploy a web application

There are two ways to deploy web services in the system.

Copy your WAR file or your web application folder (including all the contents of the web) to the $CATALINA_BASE/webapps directory.

Create a XML fragment file that contains only context content for your web service and place it in the $CATALINA_BASE/webapps directory. The web application itself can be stored anywhere on the hard drive.

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 have the extension ".war". Once Tomcat listens to the file, it (by default) unlocks the package as a subdirectory and uses the filename of the WAR file as the subdirectory name.

Next, Tomcat will create a context in memory, just as you would in a server.xml file. Of course, other necessary content will be obtained from DefaultContext in server.xml.

Another way to deploy web applications is to write a Context XML snippet file and copy it 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 fragment file is like a context element cut out of server.xml, so the fragment is named "context fragment".

For example, if we want to deploy an application called MyWebApp.war that uses realm as the access control method, we can use the following snippet:

Name the fragment "MyWebApp.xml" and copy it to the CATALINA_BASE/webapps directory.

This context snippet provides a convenient way to deploy web applications. You don't need to edit server.xml unless you want to change the default deployment features and install a new web application without restarting Tomcat.

4. Configure virtual host (Virtual Hosts)

With regard to the "Host" element in server.xml, it needs to be modified only if you set up a virtual host. A virtual host is a mechanism that serves multiple domain names on a single web server, and for each domain name, it seems to own the entire host. In fact, most small business websites are implemented with virtual hosts, mainly because virtual hosts can directly connect to Internet and provide corresponding bandwidth to ensure reasonable access response speed. In addition, virtual hosts can also provide a stable fixed IP.

A name-based virtual host can be built on any web server by establishing 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 directory. Since this article is mainly about Tomcat, we are not going to introduce how to set 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 demonstration purposes, I'll use a static host file, because this is the easiest way to test aliases.

To use a virtual host in Tomcat, you need to set up DNS or host data. To test, it is enough to set an IP alias for the local IP. Next, you need to add a few lines to the server.xml, as follows:

Tomcat's server.xml file, in its initial state, includes only one virtual host, but it can easily be 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, one of the context elements must be the default context, and the default context display path should be empty (for example, path= "").

5. Basic configuration verification (Basic Authentication)

The container-managed authentication method controls how users are authenticated when they access protected web application resources. When a web application uses Basic Authentication (the BASIC parameter is set in the auto-method element in the web.xml file), and a user accesses the protected web application, Tomcat will pop up a dialog box through HTTP Basic Authentication, asking the user to enter a user name and password. In this authentication method, all passwords will be transmitted over the network in 64-bit encoding.

Note: using Basic Authentication is considered insecure because it does not have a robust encryption method, unless HTTPS or other password plus password methods are used on both the client and server side (for example, in a virtual private network). Without additional encryption, the network administrator will be able to intercept (or abuse) the user's password.

However, if you are just starting to use Tomcat, or if you want to test container-based security management in your web application, Basic Authentication is very easy to set up and use. Just add and two elements to your web application's web.xml file, and add the appropriate and to the CATALINA_BASE/conf/tomcat-users.xml file, and then restart Tomcat.

The web.xml in the following example is extracted from a club membership website system in which only the member directory is protected and authenticated using Basic Authentication. Note that this approach will effectively replace the .htaccess file in the Apache web server.

Entire Application/members/*memberBASICMy ClubMembers-only Area VI. Configure single sign-on (Single Sign-On)

Once you have set up the realm and authentication methods, you need to do the actual user login processing. Generally speaking, it is a troublesome thing for users to log in to the system, and you must minimize the number of times users log in and verify. By default, each web application requires the user to log in when the user requests a protected resource for the first time.

If you are running multiple web applications, and each application requires separate user authentication, it looks a bit like you are fighting your users. Users don't know how to integrate multiple separate applications into a single system, so they don't know how many different applications they need to access, but they just wonder why they keep logging in.

The "single sign-on" feature of Tomcat 4 allows users to log in only once when accessing all web applications on the same virtual host. To use this feature, you only need to add a SingleSignOn Valve element to the Host, as shown below:

After the initial installation of Tomcat, server.xml 's comments include examples of SingleSignOn Valve configuration, you only need to remove the comments and you can use it. Then, as long as any user has logged in to one application, it is equally valid for all applications under the same virtual host. There are some important limitations to using single sign-on valve:

Value must be configured and nested in the same Host element, and all web applications that require a single point of validation (which must be defined by the context element) are located under that Host.

Realm, including shared user information, must be set in the same level of Host or outside of nesting.

Cannot be overwritten by realm in context.

Web applications that use single sign-on are better off using a built-in authentication method of Tomcat (defined in web.xml), which is better than custom authentication, which includes basic, digest, form and client-cert.

If you use single sign-on and want to integrate a third-party web application into your site, and this new web application uses its own authentication method instead of container-managed security, you basically have nothing to do with it. Your users need to log in once every time they log in to all the original apps, and they have to log in again when they request a new third-party app.

Of course, if you have the source code for this third-party web application, and you are a programmer, you can modify it, but it may not be easy to do.

Cookies is required for single sign-on.

7. Configure user customized directory (Customized User Directores)

Some sites allow individual users to post web pages on the server. For example, the college of a university may want to give each student a public area, or an ISP may want to give some web space to its customers, but this is not a virtual host. In this case, a typical method is to precede the user name with a special character (~) as each user's website, such as:

Http://www.cs.myuniversity.edu/~usernamehttp://members.mybigisp.com/~username

Tomcat provides two ways to map these personal sites on the host, mainly using a pair of special Listener elements. The className attribute of Listener should be the org.apache.catalina.startup.UserConfig,userClass attribute should be one of several mapping classes.

If your system is Unix, it will have a standard / etc/passwd file in which the account can be easily read by the running Tomcat, which specifies the user's home directory and uses the PasswdUserDatabase mapping class.

The web file needs to be placed in a directory like / home/users/ian/public_html or / users/jbrittain/public_html. Of course, you can also change public_html to any other subdirectory.

In fact, this user directory does not need to be located in the user's home directory at all. If you don't have a password file, but you want to map a user name to a subdirectory of a public directory like / home, you can use the HomesUserDatabase class.

This way, the web file can be located in a directory like / home/ian/public_html or / home/jasonb/public_html. This form is more advantageous for Windows, where you can use a directory like c:\ home.

These Listener elements, if present, must be inside the Host element, not the context element, because they are all applied to the Host itself.

Use CGI scripts in Tomcat

Tomcat is primarily used as a Servlet/JSP container, but it also has the performance of many traditional web servers. Support for the Universal Gateway Interface (Common Gateway Interface, or CGI) is one of them, and CGI provides a set of methods to run extensions in response to browser requests.

CGI is called generic because it can be called in most programs or scripts, including Perl,Python,awk,Unix shell scripting, etc., and even Java.

Of course, you probably won't run a Java application as CGI, after all, it's too primitive. Generally speaking, developing Servlet is always more efficient than CGI, because when a user clicks a link or a button, you don't have to start at the operating system layer.

Tomcat includes an optional CGI Servlet that allows you to run legacy CGI scripts.

In order for Tomcat to run CGI, you must do the following:

Rename servlets-cgi.renametojar (in the CATALINA_HOME/server/lib/ directory) to servlets-cgi.jar. The servlet that handles CGI should be under the CLASSPATH of Tomcat.

In Tomcat's CATALINA_BASE/conf/web.xml file, remove the comment on the paragraph about CGI (by default, it is on line 241).

Similarly, in the CATALINA_BASE/conf/web.xml file of Tomcat, remove the comment on the paragraph that maps CGI (by default, this paragraph is on line 299). Note that this section specifies how the HTML links to the CGI script.

You can put CGI scripts in the WEB-INF/cgi directory (note that WEB-INF is a safe place where you can put files that you don't want to be seen by users or that you don't want to expose for security reasons), or you can put CGI scripts in other directories under context and adjust the cgiPathPrefix initialization parameters for CGI Servlet. This specifies the actual location of the CGI Servlet and cannot have the same name as the URL specified in the previous step.

Restart Tomcat and your CGI is ready to run.

In Tomcat, CGI programs are placed under the WEB-INF/cgi directory by default, and as suggested earlier, the WEB-INF directory is protected and cannot be snooped through the client's browser, so this is a great place to place CGI scripts that contain passwords or other sensitive information.

To be compatible with other servers, although you can also save CGI scripts in the traditional / cgi-bin directory, you should know that the files in these directories may be seen by curious surfers online. Also, in Unix, make sure that the user running Tomcat has permission to execute the CGI script.

Change the JSP compiler (JSP Compiler) in Tomcat

In Tomcat 4.1 (or later, presumably), the compilation of JSP is performed directly by the Ant program controller included in Tomcat. This sounds a little strange, but this is part of Ant's intention to have an API document instructing developers to use Ant without launching a new JVM.

This is a big advantage of using Ant for Java development. In addition, it also means that you can now use any compilation supported by javac in Ant. Here is a javac page list of Apache Ant manuals.

It is easy to use because you only need to define a name called "compiler" in the element, and there is a compiler name in value that supports compilation, as shown in the example:

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.