|
Content
Overview
Technologies
Java Servlets
JavaServer Pages
Architecture
Apache
Tomcat
Java 2
Mod_Jk
Required software
Installation and Configuration
Apache 2.0.43
Java 2
Tomcat
How to integrate Tomcat in Apache
Tomcat Configuration
Deploying Web Applications to Tomcat
Creating the Web Application Directory Structure
Creating the Web Application Context
Add
a servlet entry into the web application's web.xml file
Deploying JSPs
Feedback Form
File Upload JSP using
a Java Bean
JSP for Oracle Database
Access
Deploying Servlets
HelloAkadia Servlet
Servlet for Oracle Database Access
Further Documentation
More Online Examples
Overview
Nowadays
 various
web sites are able to deal with dynamic HTML and database access. This
article shows an easy and powerful way to access an Oracle database with
Java Servlets and JavaServer Pages.
 The Java structure offers a technique
to develop fast, large and independent web applications. We especially
have a look at the Apache and Tomcat server which can handle Java Servlets and
JavaServer Pages.
Technologies
Servlets are completely
written in Java and are executed server-side. Only the first
request invokes the init() method, all requests call the service()
method which returns plain HTML code. Servlets stay in memory and are
quickly executed.
Servlets can apply the full power of
Java, for example a Servlet can process HTML forms, use own Java classes,
send an email, access a database or something else you could do with Java.
JavaServer Pages (JSP) is a
new technology to integrate server-side code into static HTML code. JSPs
are common to Active Server Pages (ASP), but have the advance
that they run with Java and therefore on almost every operating system. JSPs are
related to Java Servlets, more exact: JSPs are translated into a Java
Servlet when they are called the first time. With every request of a JSP,
the generated Java Servlet runs the service() method.
|
The main difference between Servlets and JSP is: |
In JSPs
you insert dynamic Java code into static HTML |
| |
In Java Servlets
you insert static HTML into Java code. |
Architecture
Apache or any other common web server can’t handle Servlets nor JSP. So we
use the Tomcat server from the Apache sub-project named
Jakarta. Tomcat is
the official reference implementation for the Servlet 2.3 and JSP 1.2
specification. Tomcat is a Java based web application container, is open
source and entire free to use (Tomcat is released under the Apache
software license). Tomcat is developed by a group of voluntary programmers.
Tomcat is the advancement of
JServ (JServ is an Apache module which can
serve Java Servlets, but is not under development anymore).
The Apache HTTPD server
- is a powerful, flexible, HTTP/1.1 compliant web
server
- implements the latest protocols, including HTTP/1.1
(RFC2616)
- is highly configurable and extensible with
third-party modules
- can be customised by writing 'modules' using the
Apache module API
- provides full source code and comes with an
unrestrictive license
- runs on Windows NT/9x, Netware 5.x and above,
OS/2, and most versions of Unix
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. Tomcat is developed in an open and participatory
environment and released under the
Apache Software License.
The essential Java 2 SDK, tools, runtimes, and
APIs for developers writing, deploying, and running applets and
applications in the Java programming language. Also includes Java
Development Kit release 1.1 and Java Runtime Environment 1.1.
It is the Tomcat-Apache plug-in that handles the
communication between Tomcat and Apache.
-
Termed “Web Server Adapter” or “Connector”
-
Implemented as library (mod_jk.so)
-
Uses/manages TCP connections using Port 8007
-
Uses the AJPV12/AJPV13 communication protocol
Required software
We tested the installation on the
following environment:
-
RedHat Linux 7.2 /
Apache 1.3.22
-
RedHat Linux 8.0 /
Apache 2.0.43
-
Java Development Kit (JDK) 1.3 or
1.4
-
Tomcat 4.0.4 or Tomcat 4.1.10
Installation and Configuration
RedHat Linux 8.0 delivers Apache 2.0.40 - this Release
should not be used. However it's very easy to build Apache on
RedHat Linux 8.0.
Unpack the Distribution for 2.0.43 from
http://www.apache.org/dist/httpd an build it with:
./configure --prefix=/usr/local/apache \
--enable-mods-shared=most \
--enable-ssl=shared \
--enable-mime-magic \
--enable-cern-meta \
--enable-proxy \
--enable-proxy-connect \
--enable-proxy-ftp \
--enable-proxy-http \
--enable-usertrack \
--enable-unique-id \
--enable-deflate
make
make install
cd /usr/local/apache
rm -rf logs
ln -s /var/log/httpd logs
cd /var/log
chown root:tomcat httpd
chmod 775 httpd
Download the Linux self-extracting file:
j2sdk-1_4_0_01-linux-i586.bin and copy it to e.g. /usr/local.
From this location unpack it with: ./j2sdk-1_4_0_01-linux-i586.bin
and create the following symbolic link.
lrwxrwxrwx root root java -> /usr/local/j2sdk1.4.0_01
1. Download the Tomcat binary:
jakarta-tomcat-4.1.10.tar.gz and copy it
to e.g. /usr/local.
From this location unpack it and create the following
symbolic link.
lrwxrwxrwx root root tomcat -> /usr/local/jakarta-tomcat-4.1.10
2. Create a user "tomcat" with a unique user id and group id.
The account needs an executable
login shell, and an existing home directory.
tomcat:x:411:405:Tomcat Owner:/home/tomcat:/bin/bash
3. Set the following Environment Variables:
export CATALINA_HOME=/usr/local/tomcat
export JAVA_HOME=/usr/local/java
4. Change the ownership for the conf,
temp, webapps and work directory to "tomcat".
# cd /usr/local/tomcat
# chown -R tomcat:tomcat conf temp webapps work
5. Create the following
startup script for
tomcat
6. When you start Tomcat, it runs stand-alone on port 8080. Check the
examples on http://host:8080.
| The Question |
The Answer |
|
Tomcat can handle
Java Servlets, JSP, pictures and static HTML. So why use Apache any
longer ? |
Using
Apache, the application server is more
stable, more configurable and handle HTML faster ! |
1. Copy the connector
module mod_jk-2.0.43.so to Apache and create the following
link.
# cp mod_jk-2.0.43.so /usr/local/apache/modules
# ln -s mod_jk-2.0.43.so mod_jk.so
lrwxrwxrwx 1 root root mod_jk.so
-> mod_jk-2.0.43.so
2. Add the following line at the end of the
Apache Configuration file: /usr/local/apache/conf/httpd.conf
Include /usr/local/tomcat/conf/mod_jk.conf
3. Setup the Apache -
Tomcat configuration file:
mod_jk.conf
This file instructs Apache:
-
how to load the JK module (LoadModule)
-
which URLs must be forwarded to
Tomcat (JkMount)
For example, all URLs including "/jsp/"
or "/servlet" are automatically forwarded to Tomcat with the following
directives.
JkMount /jsp/*.jsp ajp13
JkMount /servlet/* ajp13
4. Setup the worker
configuration file:
workers.properties
Usually you only have to setup the
location of Tomcat and Java and the
character for the file separator.
workers.tomcat_home=/usr/local/tomcat
workers.java_home=/usr/local/java
ps=/
5. Start Tomcat / Apache
First start Tomcat then Apache,
the order is important:
# /etc/rc.d/init.d/tomcat start
# /etc/rc.d/init.d/httpd start
You can now run the Tomcat examples on
http://host/examples through Apache. The Tomcat Server runs
now in the so called "out-of-process add-on" mode.
The Tomcat
server.xml file allows
you to configure Tomcat using a simple XML descriptor. This XML file is at
the heart of Tomcat.
The <Context> element is the most commonly
used element in the server.xml file. It represents an
individual Web Application that is running within a defined
<Host>. There is no limit to the number of contexts that can be
defined within a <Host> element. Each <Context>
definition must have a unique context path, which is defined by the path
attribute.
1. Creating the Web Application Context (Location
of the Web Application):
<!-- Tomcat Root Context -->
<Context path="/jsp" docBase="/www/webapp/jsp" debug="0" reloadable="false"
/>
-
reloadable: If set to true, causes Tomcat to
check for class changes in the WEB-INF/classes/ and
WEB-INF/lib directories. If these classes have changed, the
application owning these classes will automatically be reloaded. This
feature should only be used during development. This setting will cause
severe performance degradation, and therefore should be set to false when
in a production environment.
2. Disable Port 8080 (Port 8080 is only used in
stand-alone mode)
<!-- Define a non-SSL Coyote HTTP/1.1 Connector on port 8080 -->
<!-- (Uncommented for Productive Environment)
<Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
port="8080" minProcessors="5" maxProcessors="75"
enableLookups="true" redirectPort="8443"
acceptCount="10" debug="0" connectionTimeout="20000"
useURIValidationHack="false" />
-->
Deploying Web Applications to Tomcat
With the release of the Java Servlet Specification 2.2,
the concept of a web application was introduced. According to this
specification, a "Web Application is a collection of servlets, html pages,
classes, and other resources that can be bundled and run on multiple
containers from multiple vendors."
The following items can exist in a web application:
-
Servlets
-
JavaServer Pages
-
Utility Classes
-
Static Documents including, XHTML, images, etc.
-
Client side classes
-
Meta information that describes the web application
The container that holds the components of a web application is the
directory structure in which it exists. The first step in creating a web
application is creating this structure. The following table
contains the sample web application and what each of its directories
should contain.
|
The Web Application Directory Structure (Example) |
|
Directory |
Contains |
|
/www/webapp/jsp |
This is the root directory of the web application.
All JSP and XHTML files are stored here. |
|
/www/webapp/jsp/WEB-INF |
This directory contains all resources related to the
application that are not in the document root of the application. This
is where your web application deployment descriptor is located. Note
that the WEB-INF directory is not part of the public document. No
files contained in this directory can be served directly to a client. |
|
/www/webapp/jsp/WEB-INF/classes |
This directory is where servlet and utility classes
are located. |
|
/www/webapp/jsp/WEB-INF/lib |
This directory contains Java Archive files that the
web application depends upon. For example, this is where you would
place a JAR file that contained a JDBC driver. |
After you've created the web application directory
structure, you must add a new Context to Tomcat. The Context
defines a set of methods that are used by components of a web application
to communicate with the servlet container. The Context acts as a container
for the web application. There is only one Context per web application.
We have already done this in the
Tomcat Configuration, Step 1
If you are deploying a servlet, then you have to add a servlet entry into
the web application's web.xml file. An example
<servlet>
element can be found in the following code snippet.
<servlet>
<servlet-name>MyServlet</servlet-name>
<servlet-class>packagename.MyServlet</servlet-class>
<init-param>
<param-name>parameter</param-name>
<param-value>value</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
It isn't necessary to add all servlets to the web.xml file; it's
only necessary when the servlet requires additional information, such as
initialization parameters.
|
The Sub-elements of a <servlet> |
|
Sub-element |
Description |
|
<servlet-name> |
The <servlet-name> element is simply the
canonical name of the deployed servlet. |
|
<servlet-class> |
The <servlet-class> sub-element references
the fully qualified class name of the servlet. |
|
<init-param> |
The <init-parameter>
sub-element is an optional parameter containing a name-value pair that
is passed to the servlet on initialization. It contains two sub-elements,
<param-name>
and <param-value>, which contain the name and value,
respectively, to be passed to the servlet. |
|
<load-on-startup> |
The <load-on-startup> sub-element
indicates the order in which each servlet should be loaded. Lower positive
values are loaded first. If the value is negative or unspecified, then the
container can load the servlet at anytime during startup. |
Deploying JSPs
Now that we have created the web application directories and added the
ServletContext, you can add server-side
Java components. The first components we are going to add are JSPs.
To deploy a JSP as part of a web application you have to copy it
to the public directory of your web application, which in this case is
/www/webapp/jsp.
The first JSP will include a simple feedback screen. Add the following
line in the HTML code:
<form action="http://www.akadia.com/jsp/sendmail.jsp"
method="post">
|
Please give us your feedback regarding our website,
our services, our organization ...
We are happy to read your comments and suggestions. |
|
|
The JSP sendmail.jsp
reads the entered values in the HTML form and sends an email to the
company administrator. You can customize the Mail Host and desired Mail
Recipient:props.put("mail.smtp.host", "Enter Mail Host here");
InternetAddress to = new InternetAddress("Enter Mail Recipient here");
The second JSP uploads a local file to an upload
directory on the web application host.
You can browse your local drive and then load the
selected file to the web application host.
(Due to security reasons, this example cannot be used online ... sorry).
Show JSP
source
Show Java Bean
source
The JSP
database.jsp reads the well known EMP table from the schema SCOTT.
The database access is performed by JDBC, therefore you have to copy the
JDBC driver to the Web Application:
# cd $ORACLE_HOME/jdbc/lib
# cp *.jar /www/webapp/jsp/WEB-INF/lib
To see this JSP in action, open the following URL in a
browser:
http://www.akadia.com/jsp/database.jsp
The browser requests a JavaServer Page. Apache notice that the requested
file has a .jsp suffix
(e.g.
http://www.akadia.com/jsp/database.jsp) and forwards the
request via the connector to Tomcat. Tomcat searchs
the JavaServer Page in /www/webapp/jsp
and compile it to a Java Servlet. Then the service() method is
executed which contains the connection and query on the Oracle database.
The result of the database is written in a HTML file and sent back to the
requesting browser.
Deploying Servlets
The next component to add is a servlet. To deploy a servlet as part of
a web application you first need to compile the servlet and move it
into the web application's /WEB-INF/classes directory. For
this example, you should compile this servlet and move it to the
/www/webapp/jsp/WEB-INF/classes/
directory.
After compiling you have to add the servlet entries to the
/www/webapp/jsp/WEB-INF/web.xml file.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/j2ee/dtds/web-app_2_3.dtd">
<web-app>
<servlet>
<servlet-name>HelloAkadia</servlet-name>
<servlet-class>HelloAkadia</servlet-class>
</servlet>
<servlet>
<servlet-name>JdbcTest</servlet-name>
<servlet-class>JdbcTest</servlet-class>
</servlet>
</web-app>
The
HelloAkadia
simply echos back the request line and headers that were sent by the
client, plus any HTTPS information which is accessible.
To see this Servlet in action, open the following URL
in a browser:
http://www.akadia.com/jsp/servlet/HelloAkadia
The
JdbcTest Servlet reads the well known EMP table from the schema SCOTT.
The database access is performed by JDBC, therefore you have to copy the JDBC driver to the Web Application.
To see this Servlet in action, open the following URL in
a browser:
http://www.akadia.com/jsp/servlet/JdbcTest
Further Documentation
More Online Examples
|
