Tomcat

• Tomcat is the servlet container that is used in the official Reference Implementation for the Java Servlet and JavaServer Pages technologies. The Java Servlet and JavaServer Pages specifications are developed by Sun under the Java Community Process.
• http://jakarta.apache.org/tomcat/index.html
• Tomcat 5.x
  Tomcat 5.x is the upcoming major release of Tomcat, and builds upon the Tomcat 3.3 and Tomcat 4.1 codebases. The 5.x releases implement the Servlet 2.4 and JSP 2.0 specifications.
  
  Tomcat 4.x
  Tomcat 4.x implements a new servlet container (called Catalina) that is based on completely new architecture. The 4.x releases implement the Servlet 2.3 and JSP 1.2 specification
• We will use the current stable version Tomcat 4.1.12

Installation of Tomcat on CS Unix machines.

• Create tomcat directory under your public_html/cs526
• Download the software package from http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.12/bin/jakarta-tomcat-4.1.12.tar.gz
• tar xzvf jakarta-tomcat-4.1.12.tar.gz
• cd jakarta-tomcat-4.1.12
• We need to edit the conf/server.xml file so that it runs on port 8<last3digit of your SS#> and with limited number of child processes.
• Replace the following <Connector> tag attribute right under <!-- Define a non-SSL Coyote HTTP/1.1 Connector on port 8080 -->
  <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
  port="8888" minProcessors="2" maxProcessors="2"
  enableLookups="true" redirectPort="8443"
  acceptCount="2" debug="0" connectionTimeout="20000"
  useURIValidationHack="false" />
  
• Here we change the port number to 8888 and min/max processors to just 2. Actually it still grows to about 6.
• Read the Server Configuration Reference - Reference manual that documents all available elements and attributes that may be placed into a Tomcat 4 conf/server.xml file at http://sanluis:8888/tomcat-docs/config/index.html
• Read Tomcat Document at http://sanluis:8888/tomcat-docs/index.html for more information about the Tomcat.
• The configuration element descriptions are organized into the following major categories:

  Top Level Elements - <Server> is the root element of the entire configuration file, while <Service> represents a group of Connectors that is associated with an Engine.
  Connectors - Represent the interface between external clients sending requests to (and receiving responses from) a particular Service.
  Containers - Represent components whose function is to process incoming requests, and create the corresponding responses. An Engine handles all requests for a Service, a Host handles all requests for a particular virtual host, and a Context handles all requests for a specific web application.
  Nested Components - Represent elements that can be nested inside the element for a Container. Some elements can be nested inside any Container, while others can only be nested inside a Context.

Connector tag

• Default connector is org.apache.coyote.tomcat4.CoyoteConnector. See http://sanluis:8888/tomcat-docs/config/connectors.html
• There are two different types of connectors. Connectors that allow browsers to connect directly to the Tomcat and connectors that do it through a Web Server.

  The connectors allowing direct connections are in the binary of Tomcat. They are jar files.

  The connectors used with a Web Server are made of 2 components. One written in Java and the other written in C. The Java part is made of jar files are inclosed in the Tomcat binaries. See the Web Server Connectors table. Current mod_jk2 and mod_webapp are the two apache modules that are used for communicating with the CoyoteConnector and WarpConnector respectively on tomcat (run as servlet). mod_jk2 supports in-process JVM and load balancing.

• Apache JServ 1.0 was designed as a server application serving requests made with a specific protocol (simply enough named Apache JServ Protocol). Then, included modules allow the web server to "translate" servlet requests and forward them to the right servlet engine.
  

Context tag

• The Context element represents a web application, which is run within a particular virtual host. Each web application is based on a Web Application Archive (WAR) file, or a corresponding directory containing the corresponding unpacked contents, as described in the Servlet Specification (version 2.2 or later). For more information about web application archives, you can download the Servlet Specification, and review the Tomcat Application Developer's Guide.

• <!--
  <Context path="" docBase="ROOT" debug="0"/>
  -->

  <!-- Tomcat Examples Context -->
  <Context path="/examples" docBase="examples" debug="0"
  reloadable="true" crossContext="true">
  <Logger className="org.apache.catalina.logger.FileLogger"
  prefix="localhost_examples_log." suffix=".txt"
  timestamp="true"/>
  <Ejb name="ejb/EmplRecord" type="Entity"
  

• The web application used to process each HTTP request is selected by Catalina based on matching the longest possible prefix of the Request URI against the context path of each defined Context.
• Once selected, that Context will select an appropriate servlet to process the incoming request, according to the servlet mappings defined in the web application deployment descriptor file (which MUST be located at /WEB-INF/web.xml within the web app's directory hierarchy).

• Set the JAVA_HOME environment variable
  by adding the following lines in your .bash_profile or equivalent
  
  JAVA_HOME=/users/server/students/cs526/public_html/java/j2sdk1.4.1_01

  export PATH JAVA_HOME
  

• Let us share the j2sdk1.4.1_01 unless you need to customize the j2sdk package.
• cd bin
• run the tomcat with "./startup.sh" and shut it down with "./shutdown.sh"
• Go to any browser and type in "http://<machineDNSname>:8<last3digits of SS#>/ to verify if the tomcat is up and running.
• Try the example links. Note that some of the source code were not displayed on IE since it does not treat it as text and interpret the html tag in .txt file as web page. You need to use Netscape to see the actual jsp page when click on those source links. You can also login and use editor to see those jsp pages in /users/server/students/cs526/public_html/tomcat/jakarta-tomcat-4.1.12/webapps/examples/jsp/cal

Web Application Deployment

• Deployment Organization - Discusses the standard directory layout for a web application (defined in the Servlet API Specification), the Web Application Deployment Descriptor, and options for integration with Tomcat in your development environment.
• The top-level directory of your web application hierarchy is also the document root of your application. Here, you will place the HTML files and JSP pages that comprise your application's user interface.
• When the system administrator deploys your application into a particular server, he or she assigns a context path to your application (a later section of this manual describes deployment on Tomcat). Thus, if the system administrator assigns your application to the context path /catalog, then a request URI referring to /catalog/index.html will retrieve the index.html file from your document root.
• Standard Directory Layout
  To facilitate creation of a Web Application Archive file in the required format, it is convenient to arrange the "executable" files of your web application (that is, the files that Tomcat actually uses when executing your app) in the same organization as required by the WAR format itself. To do this, you will end up with the following contents in your application's "document root" directory:

  *.html, *.jsp, etc. - The HTML and JSP pages, along with other files that must be visible to the client browser (such as JavaScript, stylesheet files, and images) for your application. In larger applications you may choose to divide these files into a subdirectory hierarchy, but for smaller apps, it is generally much simpler to maintain only a single directory for these files.

  
  /WEB-INF/web.xml - The Web Application Deployment Descriptor for your application. This is an XML file describing the servlets and other components that make up your application, along with any initialization parameters and container-managed security constraints that you want the server to enforce for you.

  
  /WEB-INF/classes/ - This directory contains any Java class files (and associated resources) required for your application, including both servlet and non-servlet classes, that are not combined into JAR files. If your classes are organized into Java packages, you must reflect this in the directory hierarchy under /WEB-INF/classes/. For example, a Java class named com.mycompany.mypackage.MyServlet would need to be stored in a file named /WEB-INF/classes/com/mycompany/mypackage/MyServlet.class.

  
  /WEB-INF/lib/ - This directory contains JAR files that contain Java class files (and associated resources) required for your application, such as third party class libraries or JDBC drivers.

• When you install an application into Tomcat (or any other 2.2/2.3-compatible server), the classes in the WEB-INF/classes/ directory, as well as all classes in JAR files found in the WEB-INF/lib/ directory, are made visible to other classes within your particular web application.

• Tomcat 4 also supports mechanisms to install library JAR files (or unpacked classes) once, and make them visible to all installed web applications (without having to be included inside the web application itself.

• there are two locations that are commonly used within a Tomcat 4 installation for shared code:

  $CATALINA_HOME/common/lib - JAR files placed here are visible both to web applications and internal Tomcat code. This is a good place to put JDBC drivers that are required for both your application and internal Tomcat use (such as for a JDBCRealm).

  
  $CATALINA_HOME/shared/lib - JAR files placed here are visible to all web applications, but not to internal Tomcat code. This is the right place for shared libraries that are specific to your application.

  
  Out of the box, a standard Tomcat 4 installation includes a variety of pre-installed shared library files, including:

  The JavaMail 1.2 (and associated JavaBeans Activation Framework) APIs, so you can write mail-enabled web applications.

  
  The JDBC 2.0 Optional Package APIs, which define things like javax.sql.DataSource.

  
  The Servlet 2.3 and JSP 1.2 APIs that are fundamental to writing servlets and JavaServer Pages.

  
  An XML Parser compliant with the JAXP (version 1.1) APIs, so your application can perform DOM-based or SAX-based processing of XML documents.

• A web application can be deployed in Tomcat by one of the following approaches:
  • Copy unpacked directory hierarchy into a subdirectory in directory $CATALINA_HOME/webapps/. Tomcat will assign a context path to your application based on the subdirectory name you choose. We will use this technique in the build.xml file that we construct, because it is the quickest and easiest approach during development. Be sure to restart Tomcat after installing or updating your application.
  • Copy the web application archive file into directory $CATALINA_HOME/webapps/. When Tomcat is started, it will automatically expand the web application archive file into its unpacked form, and execute the application that way. This approach would typically be used to install an additional application, provided by a third party vendor or by your internal development staff, into an existing Tomcat installation. NOTE - If you use this approach, and wish to update your application later, you must both replace the web application archive file AND delete the expanded directory that Tomcat created, and then restart Tomcat, in order to reflect your changes
  • Use the Tomcat 4 "Manager" web application to deploy and undeploy web applications. Tomcat 4 includes a web application, deployed by default on context path /manager, that allows you to deploy and undeploy applications on a running Tomcat server without restarting it. See the administrator documentation (TODO: hyperlink) for more information on using the Manager web application.
  • Use "Manager" Ant Tasks In Your Build Script. Tomcat 4 includes a set of custom task definitions for the Ant build tool that allow you to automate the execution of commands to the "Manager" web application. These tasks are used in the example build script discussed later, and are explained there.
  • Add a <Context> entry in the $CATALINA_HOME/conf/server.xml configuration file. This approach is described briefly below, and allows you to position the document root of your web application at some point other than the $CATALINA_HOME/webapps/ directory. You will need to restart Tomcat to have changes in this configuration file take effect. See the administrator documentation (TODO: hyperlink) for more information on configuring new Contexts in this way.
    

Manager App HOW-TO

• To support these capabilities, Tomcat 4 includes a web application (installed by default on context path /manager) that supports the following functions:

  Deploy a new web application, on a specified context path, from the uploaded contents of a WAR file.
  Install a new web application, which can be anywhere on the server's disks.
  List the currently deployed web applications, as well as the sessions that are currently active for those web apps.
  Reload an existing web application, to reflect changes in the contents of /WEB-INF/classes or /WEB-INF/lib.
  List the available global JNDI resources, for use in deployment tools that are preparing <ResourceLink> elements nested in a <Context> deployment description.
  List the available security roles defined in the user database.
  Remove an installed web application.
  Start a stopped application (thus making it available again).
  Stop an existing application (so that it becomes unavailable), but do not undeploy it.
  Undeploy a deployed web application and delete its document base directory.

• Web Application Development Process
• On your home directory create CVS directory and underneath create CVSROOT
• Edit your shell profile, to include the CVS directory
  
  PATH=/users/server/students/cs526/public_html/java/j2sdk1.4.1_01/bin:$PATH:$HOME/bin:/sbin:/usr/sbin:/users/server/students/cs526/public_html/tomcat/jakarta-ant-1.5.1/bin

  JAVA_HOME=/users/server/students/cs526/public_html/java/j2sdk1.4.1_01
  CVSROOT=/users/server/students/cs526/CVS
  

• [cs526@sanluis cs526hw5]$ ant
  Buildfile: build.xml

  prepare:
  [mkdir] Created dir: /.automount/cs/root/usr2/students/cs526/public_html/tomcat/jakarta-tomcat-4.1.12/webapps/tomcat-docs/appdev/cs526hw5/build
  [mkdir] Created dir: /.automount/cs/root/usr2/students/cs526/public_html/tomcat/jakarta-tomcat-4.1.12/webapps/tomcat-docs/appdev/cs526hw5/build/WEB-INF
  [mkdir] Created dir: /.automount/cs/root/usr2/students/cs526/public_html/tomcat/jakarta-tomcat-4.1.12/webapps/tomcat-docs/appdev/cs526hw5/build/WEB-INF/classes
  [copy] Copying 4 files to /.automount/cs/root/usr2/students/cs526/public_html/tomcat/jakarta-tomcat-4.1.12/webapps/tomcat-docs/appdev/cs526hw5/build
  [mkdir] Created dir: /.automount/cs/root/usr2/students/cs526/public_html/tomcat/jakarta-tomcat-4.1.12/webapps/tomcat-docs/appdev/cs526hw5/build/WEB-INF/lib

  compile:
  [javac] Compiling 2 source files to /.automount/cs/root/usr2/students/cs526/public_html/tomcat/jakarta-tomcat-4.1.12/webapps/tomcat-docs/appdev/cs526hw5/build/WEB-INF/classes

  BUILD SUCCESSFUL
  Total time: 7 seconds
  [cs526@sanluis cs526hw5]$ ant install
  Buildfile: build.xml

  prepare:

  compile:

  install:
  [install] OK - Installed application at context path /cs526hw5

  BUILD SUCCESSFUL
  Total time: 5 seconds
  [cs526@sanluis cs526hw5]$
  

  [cs526@sanluis cs526hw5]$ ant reload
  Buildfile: build.xml

  prepare:

  compile:

  reload:
  [reload] OK - Reloaded application at context path /cs526hw5

  BUILD SUCCESSFUL
  Total time: 4 seconds
  

• There is a build.xml typo
  replaces
  <mkdir todir="${dist.home}/docs"/>
  with
  <mkdir dir="${dist.home}/docs"/>
  

Database access using MySQL and JDBC

• Mysql web page. http://cs.uccs.edu/~cs301/mysql/mysql.html
• JDBC. http://java.sun.com/docs/books/tutorial/jdbc/index.html
• Java-Database(Mysql) interface. http://cs.uccs.edu/~cs526/tomcat/javaDBmysql.htm