text:
Tomcat is a servlet server in the Apache Jakarta project has been widely used by programmers to develop servlets and JSP projects. The server takes up small resources, good extensibility, supports multiple functions (such as load balancing, mail services, etc., which are beneficial to the openness of the Jakarta project); more because it is a completely free and completely open server, so there is Thousands of programmers are working hard and add existing features to search for a large number of Tomcat resources and solutions on the Internet.
On http://jakarta.apache.org, you can download to Tomcat, and the latest version 5.0 is not officially released. So now available is a version 4.1.
Tomcat 4.1 can be automatically installed (you need to download the automatic installation version, there is also the version of ZIP package and source code), but you have to install JDK in advance. You can choose JDK1.3 (1.2.x or 1.3.x) or 1.4 to install. Note Download the corresponding JDK version of Tomcat. At the time of installation, if you select the installation service, the installer can automatically add Tomcat to Win NT or WIN 2000 service, the service name is "Apache Tomcat 4.1". You can find it in the service of the control panel, start / stop through the graphics interface; or use the command: Net Start "Apache Tomcat 4.1" and NET STOP "Apache Tomcat 4.1" to stop. If you need to remove the service, find Tomcat.exe in the bin directory of% Tomcat_Home% (indicating Tomcat installation directory, the same), to enter Tomcat-Remove "Apache Tomcat 4.1" in the command line, you can. If you do not choose to install the service when you automatically install, you can install it in the command line into Tomcat -Install "Apache Tomcat 4.1". In the process of installation, the console may appear without closing, then put the control focus on the console, press the Enter key to continue the installation.
The Servlet 2.3 and JSP L.2 engines are implemented inside Tomcat 4.1. If you need to use a database connection pool, you must use Tomcat4.1 or later, because Tomcat 4.1 starts support for the database connection pool. For the configuration of the Tomcat built-in connecting pool, see the steps:
1. Look for third-party database Java drivers (such as DB2 drivers are db2java.zip files), and copy it to Tomcat's library file directory. Here is the% Tomcat_Home% of the CommON / lib sub-directory. Note, be sure to turn the file into .jar file, copy it. Otherwise, there may be a problem that the driver may be present.
2. Configure the server.xml file under the% Tomcat_Home% of the confes. Under the Host branch, remove unnecessary contexts (such as the initial installation that may be installed, etc., annotate the related description). Add your own context, the following is an example of an annotation description:
prefix = "localhost_ppc_log." suffix = ". txt" TimeStamp = "true" /> Auth = "container" TYPE = "javax.sql.datasource" />
Configure your mysqld max_connections large enough to handle All of Your DB Connections. Set to 0 for no limit. Maximum number of connections ->
Set to 0 for no limit. Maximum idle connection ->
IN ms, in this example 10 seconds. An Exception Is Thrown IF THIS TIMEOUT IS EXCEEDED. SET to -1 to wait indefinitely. The longest waiting connection time, if set to -1 indicate uncertain ->
DB2 DB Username and Password for DB Connections What is configured here is DB2 connection ->
JDBC connection URL name The DB2 control terminal has been installed here. -> 3. WEB-APPs (deployed web applications) in the corresponding use to the connection pool, generally change the Web-INF below the WebAPPS directory of% tomcat_home% .xm L, add the data source within the web-app branch, see the example below: This is completely configured with such a connection pool. In the program, you can use as the standard J2EE's writing, see the following example: Context ctx = new initialContext (); // Create a context instance DataSource DS = (DataSource) CTX.lookup "Java: Comp / Env / JDBC / EMR"); // Get a data source (connected pool) IF (ds! = null) Connection conn = ds.getConnection (); // Get a connection from the connection pool 4. Commissioning and testing It generally has such problems in the configuration, which can write a simple debug code to find the problem. The following is a piece of code snippet, you can refer to the order of the code segmentation step by step: Try {class.Forname ("com.ibm.db2.jdbc.app.db2driver");} // 1. Can I find a database driver? Catch (ClassNotfoundException CNFE) {Out.println (cnfe.tostring ());} // Cannot find, print errors Javax.naming.context ctx = new javax.naming.initialcontext (); Javax.naming.context envcontext = (javax.naming.context) CTX.lookup ("java: / comp / ENV"); // 2. Can you find the environment's namespace Out.printLn (EnvContext); // Can't find, print error org.apache.commons.dbcp.basicDataSource DS = (org.apache.commons.dbcp.basicDataSource) ENVCONTEXT.LOOKUP ("JDBC / EMR"); //// 3. Can you get a data source. Here, you must receive more specific information than the DataSource interface to get the error search. IF (ds == null) Out.println (DS); / / Can't find, print errors Else { // 4. What is the specific information of the data source Is there any read from Server.xml? // You can also look at USRNAME, URL, etc. Out.println (DS.GetValidationQuery ()); Out.println (ds.getmaxactive ()); Out.println (DS.GetPassword ()); Out.println (ds.getdriverclassname ()); } Generally, the above four steps can be determined where the error is. The following sections primarily talk about Tomcat coding problems. The code of Tomcat, which is generally referred to whether JSP or servlet encoding is garbled, resolving as follows: 1. Places that appear in Tomcat Code: Tomcat's encoding problem is more annoying, generally in a compile stage, print phase, or request reception phase. 2. Compile stage encoding problem resolution: Coding problems in the compilation phase can force the code used to specify the compiler. Under the% Tomcat_Home% confes, edit web.xml, find This description, add sublays below the servlet Where ISO-8859-1 can be replaced with the code you need, such as GB2312; if not specified, it is UTF-8. Note that the compiler cannot recognize GBK, so do not use GBK as encoding. 3. Page print to the screen phase to solve the problem Encoding If garbled occurs when printing at the JSP page, you can consider the encoding of the page. Just join in JSP <% @ Page ContentType = "Text / HT ML; Charset = GB2312 "%> The tag can be (Simplified Chinese, other encoding you modify the value after charset). 4. Solution to the Request Receive Phase Coding Problem If there is garbled when receiving another page or the page itself is transferred, it can be set to resolve the Request's encoding, as long as the servlet program or JSP page is starting to join Request.setCharacterencoding ("GB2312"); // GB2312 is Simplified Chinese, other coding makes corresponding modifications This piece can be. However, such a suspicion of the transplantability of destruction procedures. Because if another SERLET engine is just because of joining this statement, there is a garbled, it is not good. Therefore, you can have the following two ways to solve this problem. 4.1 Write the include file, add two words of the encoded to the included JSP file. If there is a garbled because of manual coding, you can modify the included JSP file to solve all encoding problems. Such as: 4.2 Write a servlet filter. The setting of the Request's encoding is resolved by a filter. This method does not need to change the original code, it is better. The ready-made filter code is posted below, as long as it is compiled, it can be used: Package filters; Import java.io.ioException; Import javax.servlet.filter; Import javax.servlet.filterchain; Import javax.servlet.filterconfig; Import javax.servlet.servletException; Import javax.servlet.servletRequest; Import javax.servlet.servletResponse; Import javax.servlet.unavailableException; / ** * EXAMPLE FILTER THATS The Character Encoding to Be Used In Parsing The * Incoming Request, Either Unconditionally or Only If The Client Did Not * Specify a character encoding. * If there is no provision of the request, set; otherwise keep the same * / Public class setcharacterencodingfilter imports filter { protected string encoding = null; Protected filterconfig filter firmconfig = NULL; Protected boolean ignore = true; / ** * Take this filter out of service. * / Public void destroy () { THIS.Encoding = NULL; THIS.FILTERCONFIG = NULL; } / ** * Select and set (if specified) The character encoding to be used to * Interpret Request Parameters for this Request. * / Public Void Dofilter (ServletRequest Request, ServletResponse Response, FILTERCHAIN chain THROWS IOException, servletexception { // conditionally select and set the character encoding to be available IF (ignore || (Request.getCharacterencoding () == null) { String Encoding = SELECTENCODING (Request); IF (Encoding! = NULL) Request.setCharacterencoding (Encoding); // Setting the REQUEST encoded place} // Pass Control on to the next filter // Transfer control to the next filter Chain.dofilter (Request, Response); } / ** * Place this Filter INTO Service. * Read the value of the initial parameters from the web-app's web.xml file * / Public void init (filterconfig filterconfig) throws servletexception { THIS.FILTERCONFIG = FilterConfig; this.encoding = filterconfig.getinitParameter ("encoding"); String value = filterconfig.getinitparameter ("ignore"); IF (value == null) THIS.IGNORE = TRUE; Else IF (Value.equalsignorecase ("True")) THIS.IGNORE = TRUE; Else IF (Value.Equalsignorecase ("YES")) THIS.IGNORE = TRUE; Else THIS.IGNORE = FALSE; } / ** * Select An appropriate Character Encoding to be used, based on the * CHARACTERISTICS OF THE CURRENT REQUEST AND / OR Filter Initialization * Parameters. if no character encoding shop be set, return * * Select the original code of Request * / protected string selectencoding (servletRequest request) { Return (this.encoding); } } After compiling, add setCharacterencodingFilter.class to the corresponding web-app's web-imp / classs / filter, and add the following statement to the web-app on Web.xml, configure this as a servlet: 5. Additional solutions for encoding problems: Globalization solutions. The above configuration is completed is a localized problem. However, we can use the same coding in all the processes, such as ISO-8859-1, which is large enough. Because Java is the design of Unicode, as long as the information is distorted in the code delivery, the coding problem can be pushed to the final display, and the globalization is achieved. The key is not to appear high levels of encoding. Generally, the code appears when the symbol appears on the page. Other questions from Tomcat: Tomcat 4.1 may not be as stable as RESIN 2.1, with some weird bugs. But more flexible than RESIN, because it is part of the Jakarta project, a lot of components, and more expandability. Therefore, it is also more suitable for development and research. The following is such a strange bug: When Tomcat is used as a JSP server, this is written in the JSP statement. The statement in the principle, "<%" and "%>" is a dynamic statement, and they are a static statement outside. Note should only be valid. This is true in RESIN, normal. But under Tomcat4.1, ">" outside is actually commented. Proof Tomcat's grammatical analysis is still a bit problem. I hope that when 5.0 is officially released, I have seen it has fallen. null . ">
