Sun Java System Web Server 6.1 SP6 Programmer's Guide to Web Applications

Chapter 1 Web Applications

This chapter provides a basic overview of how web applications are supported in the Sun JavaTM System Web Server 6.1.

This chapter includes the following sections:

Introducing Web Applications

Sun Java System Web Server 6.1 supports the Java™ Servlet 2.3 API specification and the JavaServer Pages (JSP) 1.2 specification, which allows servlets and JSPs to be included in web applications.

A web application is a collection of servlets, JavaServer Pages, HTML documents, and other web resources that might include image files, compressed archives, and other data. A web application can be packaged into a Web ARchive file (a WAR file) or exist in an open directory structure.

In addition, Sun Java System Web Server 6.1 supports SHTML and CGI, which are non-Java™ 2 Platform, Standard Edition (J2SE platform) application components.

This section includes summaries of the following topics:


Java servlets are server-side Java programs that application servers can run to generate content in response to a client request. Servlets can be thought of as applets that run on the server side without a user interface. Servlets are invoked through URL invocation or by other servlets.

Sun Java System Web Server 6.1 supports the Java Servlet 2.3 specification.

Note –

Java Servlet API version 2.3 is fully compatible with versions 2.1 and 2.2, so all existing servlets will continue to work without modification or recompilation.

To develop servlets, use Sun's Java Servlet API. For information about using the Java Servlet API, see the documentation provided by Sun at:

For the Java Servlet 2.3 specification, please visit:

For information about developing servlets in Sun Java System Web Server, see Chapter 3, Using Servlets.


Sun Java System Web Server 6.1 supports the JSP 1.2 specification.

A JSP is a page, much like an HTML page, that can be viewed in a web browser. However, in addition to HTML tags, it can include a set of JSP tags and directives intermixed with Java code that extend the ability of the web page designer to incorporate dynamic content in a page. These additional features provide functionality such as displaying property values and using simple conditionals.

One of the main benefits of JSPs is that they are like HTML pages. The web page designer simply writes a page that uses HTML and JSP tags and puts it on his or her web server. The page is compiled automatically when it is deployed. The web page designer needs to know little about Java classes and Java compilers. Sun Java System Web Server supports precompilation of JSPs, however, and this is recommended for production servers.

JSP pages can access full Java functionality by:

Servlets are Java classes that must be compiled, but they can be defined and compiled by a Java programmer, who then publishes the interface to the servlet. The web page designer can access a precompiled servlet from a JSP page.

Sun Java System Web Server 6.1 supports JSP tag libraries and standard portable tags.

For information about creating JSPs, see Sun's JavaServer Pages web site at:

For information about developing JSPs in Sun Java System Web Server, see Chapter 4, Using JavaServer Pages.


HTML files can contain tags that are executed on the server. In addition to supporting the standard server-side tags, or SSIs, Sun Java System Web Server 6.1 allows you to embed servlets and define your own server-side tags. For more information, see the Sun Java System Web Server 6.1 SP6 Programmer’s Guide.


Common Gateway Interface (CGI) programs run on the server and generate a response to return to the requesting client. CGI programs can be written in various languages, including C, C++, Java, Perl, and as shell scripts. CGI programs are invoked through URL invocation. Sun Java System Web Server complies with the version 1.1 CGI specification. For more information, see the Sun Java System Web Server 6.1 SP6 Programmer’s Guide.

Creating a Web Application

ProcedureTo create a web application

  1. Create a directory for all of the web application's files. This is the web application's document root.

  2. Create any needed HTML files, image files, and other static content. Place these files in the document root directory or a subdirectory where they can be accessed by other parts of the application.

  3. Create any needed JSP files. For more information, see Chapter 4, Using JavaServer Pages

  4. Create any needed servlets. For more information, see Chapter 3, Using Servlets

  5. Compile the servlets. For details about precompiling JSPs, see Compiling JSPs: The Command-Line Compiler

  6. Organize the web application as described in Web Application Structure

  7. Create the deployment descriptor files. For more information, see Creating Web Deployment Descriptors

  8. Package the web application in a .war file . This is optional. For example:

    jar -cvf module_name.war *

  9. Deploy the web application. For more information, see Deploying Web Applications

    You can create a web application manually, or you can use Sun™ Java System Studio.

Securing a Web Application

You can write secure web applications for the Sun Java System Web Server with components that perform user authentication and access authorization. You can build security into web applications using the following mechanisms:

For detailed information about these mechanisms, see Chapter 6, Securing Web Applications.

Deploying a Web Application

Web application deployment descriptor files are packaged within .war files. They contain metadata and information that identifies the servlet or JSP, and establishes its application role. For more information about these descriptor files, see Chapter 7, Deploying Web Applications.

Virtual Servers

A virtual server is a virtual web server that uses a unique combination of IP address, port number, and host name to identify it. You might have several virtual servers, all of which use the same IP address and port number but are distinguished by their unique host names.

When you first install Sun Java System Web Server, a default virtual server is created. You can also assign a default virtual server to each new HTTP listener you create. For details, see the Sun Java System Web Server 6.1 SP6 Administrator’s Guide.

Web applications can be hosted under virtual servers.

Default Web Applications

A web application that is deployed in a virtual server at a URI ”/’ becomes the default web application for that virtual server. For details, see Virtual Servers virtual server, point your browser to the URL for the virtual server, but do not supply a context root. For example:


If none of the web applications under a virtual server are deployed at the URI ”/’, the virtual server serves HTML or JSP content from its document root, which is usually install_dir/docs. To access this HTML or JSP content, point your browser to the URL for the virtual server, and do not supply a context root but rather specify the target file. For example:


Servlet and JSP Caching

The Sun Java System Web Server has the ability to cache servlet or JSP results in order to make subsequent calls to the same servlet or JSP faster.

The Sun Java System Web Server caches the request results for a specific amount of time. In this way, if another data call occurs, the Sun Java System Web Server can return the cached data instead of performing the operation again. For example, if your servlet returns a stock quote that updates every 5 minutes, you set the cache to expire after 300 seconds.

For more information about response caching as it pertains to servlets, see Caching Servlet Results.

For more information about JSP caching, see JSP Cache Tags.

Database Connection Pooling

Database connection pooling enhances the performance of servlet or JSP database interactions. For more information about Java™ DataBase Connectivity (JDBC™), see the Sun Java System Web Server 6.1 SP6 Administrator’s Guide.

Configuring the Web Container

You can configure logging in the web container for the entire server by:

Web Application Samples

Sun Java System Web Server 6.1 includes a set of sample web applications, which can be found in the following directory:


The directory contains the directories and samples listed in the following table. It also contains an index.html file that provides more information about configuring and deploying the samples.

Table 1–1 Sample Directories




JSP and servlet examples that demonstrate how to cache results of JSP and servlet execution. 


A basic J2SE web application that demonstrates how to dynamically change the display language based on user preference. 


A servlet that uses the Javamail API to send an email message. 


Java DataBase Connectivity examples in the following directories: 

  • blob: A servlet that accesses Binary Large Objects (BLOBs) via JDBC.

  • simple: A basic servlet that accesses an RDBMS via JDBC.

  • transactions: A servlet that uses the transaction API with JDBC to control a local transaction.


Java Naming and Directory Interface™ examples in the following directories: 

  • custom: Demonstrates using the custom resource.

  • external: Demonstrates using the external resource.

  • readenv: Demonstrates using the environment entries specified in the web.xml file.

  • url: A servlet that uses the URL resource facility to access a resource.


Basic examples that demonstrate usage of the JSP Standard Tag Library. 


Basic example that demonstrates using a servlet to access a stateless EJB™ using RMI/IIOP running in Sun™ Java System Application Server 7. 


Security examples in the following directories: 

  • basic-auth: Demonstrates how to develop, configure, and exercise basic authentication.

  • client-cert: Demonstrates how to develop, configure, and exercise client certificate authentication.

  • form-auth: Demonstrates how to develop, configure, and exercise form-based authentication.

  • jdbcrealm: Demonstrates how to develop, configure, and exercise JDBC realm authentication.


Basic JSP and servlet examples combined into a single web application (Tomcat 3.2.2 samples). 

You can also deploy these examples using the wdeploy utility. For more information about this utility, see Deploying Web Applications.