Previous Contents Index Next |
Sun Java System Application Server Standard and Enterprise Edition 7 2004Q2 Developer's Guide to Web Applications

> ## Chapter 1
> Web Applications

> This chapter describes how web applications are supported in the Sun Java™ System Application Server 7, Enterprise Edition, and includes the following sections:

> - Introducing Web Applications
> - Creating a Web Application
> - Deploying a Web Application
> - Debugging a Web Application
> - Internationalization Issues
> - Virtual Servers
> - Default Web Modules
> - Servlet and JSP Caching
> - Database Connection Pooling
> - Configuring the Web Container
> - Web Application Examples

> ##

> Introducing Web Applications

> Sun Java System Application Server 7 supports the Java™ Servlet 2.3 API specification, which allows servlets and JavaServer Pages™ (JSP™) pages to be included in web applications.

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

> The following figure illustrates details of the Java™ 2 Platform, Enterprise Edition (J2EE™ platform) environment. Web applications are in the presentation layer. Two web applications are running in the web container: one of them is part of a full application that includes Enterprise JavaBeans™ (EJB™) modules and connectors, while the other is an individually deployed web module.

> Figure 1-1 Web applications in the J2EE environment

> In addition, Sun Java System Application Server 7 supports SHTML and CGI, which are non-J2EE application components.

> This section includes summaries of the following topics:

> - Servlets
> - JavaServer Pages
> - SHTML
> - CGI

> ### Servlets

> 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 Application Server 7 supports the Java Servlet Specification version 2.3.

> Note | Servlet API version 2.3 is fully backward 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 Microsystems’ Java Servlet API. For information about using the Java Servlet API, see the documentation provided by Sun Microsystems at:

> http://java.sun.com/products/servlet/index.html

> For information about developing servlets inSun Java System Application Server, see Chapter 2, “Using Servlets.”

> ### JavaServer Pages

> Sun Java System Application Server 7 supports JavaServer Pages (JSP) Specification version 1.2.

> 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 their application server. The page is compiled automatically when it is deployed. What the web page designer needs to know about Java classes and Java compilers is minimal.

> Sun Java System Application Server supports precompilation of JSPs, however, and this is especially useful for production servers.

> JSP pages can access full Java functionality in the following ways:

> - by embedding Java code directly in scriptlets in the page
> - by accessing Java beans
> - by using server-side tags that include Java servlets

> Both beans and servlets are Java classes that need to be compiled, but they can be defined and compiled by a Java programmer, who then publishes the interface to the bean or the servlet. The web page designer can access a pre-compiled bean or servlet from a JSP page.

> Sun Java System Application Server 7 supports JSP tag libraries and standard portable tags.

> For information about creating JSPs, see Sun Microsystem’s JavaServer Pages web site at:

> http://java.sun.com/products/jsp/index.html

> For information about Java Beans, see Sun Microsystem’s JavaBeans web page at:

> http://java.sun.com/beans/index.html

> For information about developing JSPs inSun Java System Application Server, see Chapter 3, “Using JavaServer Pages.”

> ### SHTML

> 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 Application Server 7 allows you to embed servlets and define your own server-side tags. For more information, see Chapter 7, “Using Server-Parsed HTML.”

> ### CGI

> 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 Application Server complies with the version 1.1 CGI specification. For more information, see Chapter 8, “Using CGI.”

> ##

> Creating a Web Application

> To create a web application:

> 1. Create a directory for all 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 3, “Using JavaServer Pages.”
> 4. Create any needed servlets. For more information, see Chapter 2, “Using Servlets.”
> 5. Compile the servlets. For details about precompiling JSPs, see “Compiling JSPs: The Command-Line Compiler” on page 61.
> 6. Organize the web application as described in “Web Application Structure” on page 94.
> 7. Create the deployment descriptor files. For more information, see Chapter 6, “Assembling and Deploying Web Modules.”
> 8. Package the web application in a WAR file if desired. This is optional. For example:

> jar -cvf module_name.war *

> 9. Deploy the web application. For more information, see Chapter 6, “Assembling and Deploying Web Modules.”

> You can create a web application by hand, or you can use Sun ONE Studio 5. For more information about Sun ONE Studio, see the Sun ONE Studio 5, Enterprise Edition Tutorial.

> ##

> Deploying a Web Application

> Web application deployment descriptor files are created by the Sun Java System Application Server Administration interface during deployment. You can also create these by hand. These descriptor files are packaged within Web Application aRchive (.war) files. They contain metadata, plus information that identifies the servlet or JSP and establishes its application role. For more information about these descriptor files, see Chapter 6, “Assembling and Deploying Web Modules.”

> ##

> Debugging a Web Application

> For information about debugging applications, see the Sun Java System Application Server Developer’s Guide.

> ##

> Internationalization Issues

> This section covers internationalization as it applies to the following:

> - The Server
> - Servlets
> - JSPs

> ### The Server

> To set the default locale of the entire Sun Java System Application Server, which determines the locale of the Administration interface, the logs, and so on, do one of the following:

> - Go to the server instance page of the Administration interface, click on the Advanced tab, type a value in the Locale field, click on the Save button, click on the General tab, and select the Apply Changes button.
> - Set the locale attribute of the server element in the server.xml file, then restart the server. For more information about this file, see the Sun Java System Application Server Administrator’s Configuration File Reference.

> ### Servlets

> This section explains how the Sun Java System Application Server determines the character encoding for the servlet request and the servlet response.

> For encodings you can use, see:

> http://java.sun.com/j2se/1.4/docs/guide/intl/encoding.doc.html

> #### Servlet Request

> When processing a servlet request, the server uses the following order of precedence, first to last, to determine the request character encoding:

> - The setCharacterEncoding() method.
> - A hidden field in the form, specified by the parameter-encoding element in the sun-web.xml file. For more information, see “parameter-encoding” on page 133.
> - The character encoding set in the locale-charset-info element in the sun-web.xml file. For more information about this element, see “Internationalization Elements” on page 132.
> - The default, which is ISO-8859-1.

> #### Servlet Response

> When processing a servlet response, the server uses the following order of precedence, first to last, to determine the response character encoding:

> - The setContentType() method.
> - The setLocale() method.
> - The default, which is ISO-8859-1.

> To send non-ASCII characters in the response headers, set the useResponseCTForHeaders property, which is described in the section “sun-web-app” on page 103.

> ### JSPs

> For encodings you can use, see:

> http://java.sun.com/j2se/1.4/docs/guide/intl/encoding.doc.html

> To set the character encoding of a JSP, use the page directive. For example:

> <%@ page contentType="text/html; charset=Shift_JIS" %>

> The contentType attribute defines the following:

> - The character encoding for the JSP page.
> - The character encoding for the response of the JSP page.
> - The MIME type for the response of the JSP page.

> The default value is text/html; charset=ISO-8859-1.

> When processing a JSP page, the server uses the following order of precedence, first to last, to determine the character encoding:

> - The page directive and contentType attribute of JSP file.
> - The default, which is ISO-8859-1.

> Some JSP pages can deliver content using different content types and character encodings depending on the request time input. Dynamic setting of content type relies on an underlying invocation of response.setContentType(). This method can be invoked as long as no content has been sent to the response stream.

> ##

> Virtual Servers

> A virtual server, also called a virtual host, is a virtual web server that serves content targeted for a specific URL. Multiple virtual servers may serve content using the same or different host names, port numbers, or IP addresses. The HTTP service can direct incoming web requests to different virtual servers based on the URL.

> When you first install Sun Java System Application 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 Application Server Administrator’s Guide.)

> Web applications and J2EE applications containing web components can be assigned to virtual servers. You can assign virtual servers in either of these ways:

> - Using the Administration Interface
> - Editing the server.xml File

> ### Using the Administration Interface

> You can assign a virtual server to a web module during deployment as described in “Deploying Web Applications” on page 96. To use the Administration interface to specify a virtual server’s default web module:

> 1. Deploy the web application or J2EE application as described in “Deploying Web Applications” on page 96.
> 2. Open the HTTP Server component under your server instance.
> 3. Open the Virtual Servers component under the HTTP Server component.
> 4. Select the virtual server to which you want to assign the web application.
> 5. Select the web application from the Default Web Module drop-down list.
> 6. Select the Save button.
> 7. Go to the server instance page and select the Apply Changes button.

> For more information, see Default Web Modules.

> ### Editing the server.xml File

> When a web module is deployed as part of an application, a j2ee-application element is created for it in server.xml during deployment. When a web module is deployed as an individual module, a web-module element is created for it in server.xml during deployment. The j2ee-application and web-module elements both have a virtual-servers attribute, which specifies a list of virtual server IDs. The virtual-servers attribute is empty by default, which means that the web application is assigned to all virtual servers.

> Each virtual-server element in server.xml has a default-web-module attribute, which allows you to configure a default web module for each virtual server. A default web module for the default virtual server is provided at installation. For more information, see Default Web Modules.

> For more information about server.xml and virtual servers, see the Sun Java System Application Server Administrator’s Configuration File Reference.

> ##

> Default Web Modules

> You can assign a default web module to the default virtual server and to each new virtual server you create. For details, see Virtual Servers. To access the default web module for a virtual server, point your browser to the URL for the virtual server, but do not supply a context root. For example:

> http://myvserver:3184/

> A virtual server with no default web module assigned serves HTML or JSP content from its document root, which is usually instance_dir/docroot. To access this HTML or JSP content, point your browser to the URL for the virtual server, do not supply a context root, but specify the target file.

> For example:

> http://myvserver:3184/hellothere.jsp

> ##

> Servlet and JSP Caching

> The Sun Java System Application 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 Application Server caches the request results for a specific amount of time. In this way, if another data call occurs the Sun Java System Application 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” on page 47. For more information about JSP caching, see “JSP Caching” on page 58.

> ##

> Database Connection Pooling

> Database connection pooling enhances the performance of servlet or JSP database interactions. There are several Java™ Database Connectivity (JDBC™) 2.0 compatible drivers that support connection pooling, for example Pointbase, Oracle 8i update, and CloudScape 3.0. For more information about JDBC, see the Sun Java System Application Server Developer’s Guide to J2EE Services and APIs.

> ##

> Configuring the Web Container

> You can configure logging in the web container for the entire server in these ways:

> - By using the Administration interface; see the Sun Java System Application Server Administrator’s Guide.
> - By editing the server.xml file; see the Sun Java System Application Server Administrator’s Configuration File Reference.

> ##

> Web Application Examples

> Sample web applications that you can examine and deploy are included in Sun Java System Application Server, in the install_dir/samples/webapps directory. Each sample has its own documentation.

> Previous Contents Index Next

> Copyright 2004 Sun Microsystems, Inc. All rights reserved.