Chapter 21: Creating Web Applications
Web applications contain the following components.
Servlets are Java classes that create HTML pages with dynamic content and respond to requests from client applications that are implemented as HTML forms. Servlets also allow you to execute business logic from a Web browser or any other client application that connects using the Hypertext Transfer Protocol (HTTP). For more information on creating servlets, see Chapter 22, “Creating Java Servlets.”
Web clients invoke your Web application’s servlets by prepending the Web application’s root request path to an alias that is mapped to the servlet. For example, the following URL invokes a servlet mapped to the alias “Account” in the application with root request path “Finance”:
JavaServer Pages (JSP) allow you to embed snippets of Java code into HTML pages to create dynamic content. JSP tag libraries allow you to extend the standard HTML markup tags with custom tags backed by Java classes. See Chapter 24, “Creating JavaServer Pages,” for more information on creating JSPs.
Files that provide static content for the site can be included in the Web site, including HTML, images, sounds, and so forth. You can also include Java applet files. You can configure the application’s deployment descriptor to specify security constraints for static files and any unique MIME types required by your content.
Static files must be deployed to the following subdirectory in your EAServer installation directory:
Where web-app is the name of the Web application. You can include subdirectories, which are reflected in your application’s URL namespace.
If you import a Web archive (WAR) file, the importer expands the application’s static files to this location.
A Web application’s Java classes include the implementation class for each servlet and JSP, and any server-side utility classes used by the servlets and JSPs.
EAServer uses a custom class loader to run a Web application’s servlets and classes referenced by servlet and JSP code. This feature allows hot refresh of servlets and JSPs. The custom class loader also allows each Web application to run with its own effective Java class path. To work with the custom loader and support hot refresh, you must deploy your Web application classes as described below.
You can deploy class files in the following locations, where app_name is the name of the Web application:
Repository/WebApplication/app_name/WEB-INF/classes – for class files used by servlets and JSPs in the Web application.
Repository/WebApplication/app_name/WEB-INF/lib – for classes contained in JAR files. All JAR files in this directory are automatically part of the Web application’s effective class path.
Your Web application may use classes or JAR files that are used by Java or EJB clients and components. These files can be deployed in the EAServer java/classes or html/classes subdirectories. Classes and JAR files loaded from these locations cannot be refreshed unless added to the custom class list for the servlet or Web application. “Custom class lists for Web applications” describes how to extend the custom class list for servlets and Web applications. You can also load JAR files from the EAServer extensions directory, as described in “Using Java extensions”.
In order to allow hot refresh, class references in your servlet and JSP code must be resolved by EAServer’s custom class loader. Class instances loaded by the system class loader cannot be refreshed. Class instances loaded by the custom class loader cannot be assigned to references loaded by the system class loader, or vice-versa.
Most all references will be resolved by the custom loader. The exceptions are references made with class loader calls with an explicit reference to the system class loader or another custom class loader. The following class references are all resolved by the custom class loader when they occur in servlet code:
Classes referenced by import statements and declarations.
Classes loaded dynamically using Class.forName(String). For example:
obj = Class.forName("com.foo.MyClass");
Classes loaded by explicitly calling the java.lang.ClassLoader associated with the servlet instance, which can be retrieved with this code (this refers to the servlet instance):
ClassLoader loader = this.getClassLoader();
Code that uses the system class loader should be rewritten to use the servlet class loader when possible. The system class loader cannot load classes from the Web application WEB-INF/classes or WEB-INF/lib directories unless you add these locations to the server BOOTCLASSPATH and CLASSPATH environment variables. Classes loaded by the system class loader cannot be refreshed while the server is running.
The application’s deployment descriptor catalogs the servlets, JSPs, and files contained in the application, as well as the properties of each. The descriptor must be formatted in XML, using the DTD specified in the Java Servlet Specification Version 2.3. You can create a descriptor using EAServer Manager or another J2EE-compliant development tool.
EAServer maintains the deployment descriptor in two formats, the EAServer repository format, using property files, and in XML, using the standard DTD required for compatibility with the Java Servlet Specification. When you import a Web application from a WAR file, the XML descriptor is converted to repository format. Changes made in EAServer Manager are saved in the Repository format, and the XML descriptor is updated when the server is next refreshed or restarted.
|Copyright © 2005. Sybase Inc. All rights reserved.|