Creating and Configuring Web Applications

2 Creating and Configuring Web Applications

Learn how to create and configure WebLogic Web applications.

This chapter includes the following sections:

WebLogic Web Applications and Java EE

The Java EE programming model employs metadata annotations which simplify the application development process by allowing a developer to specify within the Java class itself how the application component behaves in the container, requests for dependency injection, and so on. Annotations are an alternative to deployment descriptors that were required by older versions of enterprise applications (Java EE 1.4 and earlier).

With Java EE annotations, the standard application.xml and web.xml deployment descriptors are optional. The Java EE programming model uses the JDK annotations feature for Web containers, such as EJBs, servlets, Web applications, and JSPs. See WebLogic Annotation for Web Components and http://docs.oracle.com/javaee/7/api/. For more information about Java EE 7 Web application technologies, see http://www.oracle.com/technetwork/java/javaee/tech/index.html.

However, Web applications deployed on WebLogic Server can still use a standard Java EE deployment descriptor file and a WebLogic-specific deployment descriptor file to define their resources and operating attributes.

Directory Structure

Web applications use a standard directory structure defined in the Java EE specification. You can deploy a Web application as a collection of files that use this directory structure, known as exploded directory format, or as an archived file called a WAR file. Oracle recommends that you package and deploy your exploded Web application as part of an enterprise application. This is an Oracle best practice which allows for easier application migration, additions, and changes. Also, packaging your Web application as part of an enterprise application allows you to take advantage of the split development directory structure, which provides a number of benefits over the traditional single directory structure.

The WEB-INF directory contains the deployment descriptors for the Web application (web.xml and weblogic.xml) and two subdirectories for storing compiled Java classes and library JAR files. These subdirectories are respectively named classes and lib. JSP taglibs are stored in the WEB-INF directory at the top level of the staging directory. The Java classes include servlets, helper classes and, if desired, precompiled JSPs.

All servlets, classes, static files, and other resources belonging to a Web application are organized under a directory hierarchy.

The entire directory, once staged, is bundled into a WAR file using the jar command. The WAR file can be deployed alone or as part of an enterprise application (recommended) with other application components, including other Web applications, EJB components, and WebLogic Server components.

JSP pages and HTTP servlets can access all services and APIs available in WebLogic Server. These services include EJBs, database connections through Java Database Connectivity (JDBC), JavaMessaging Service (JMS), XML, and more.

Accessing Information in WEB-INF

The WEB-INF directory is not part of the public document tree of the application. No file contained in the WEB-INF directory can be served directly to a client by the container. However, the contents of the WEB-INF directory are visible to servlet code using the getResource and getResourceAsStream() method calls on the ServletContext or includes/forwards using the RequestDispatcher. Hence, if the application developer needs access, from servlet code, to application specific configuration information that should not be exposed directly to the Web client, the application developer may place it under this directory.

Since requests are matched to resource mappings in a case-sensitive manner, client requests for "/WEB-INF/foo", "/WEb-iNf/foo", for example, should not result in contents of the Web application located under /WEB-INF being returned, nor any form of directory listing thereof.

Directory Structure Example

The following is an example of a Web application directory structure, in which myWebApp/ is the staging directory:

Example 2-1 Web Application Directory Structure

myWebApp/
  WEB-INF/
    web.xml
    weblogic.xml
    lib/
      MyLib.jar
    classes/
      MyPackage/
        MyServlet.class
  index.html
  index.jsp

Main Steps to Create and Configure a Web Application

Learn how to create a Web application as part of an enterprise application using the split development directory structure.

See Creating a Split Development Directory Environment, Building Applications In a Split Development Directory, and Deploying and Packaging From a Split Development Directory in Developing Applications for Oracle WebLogic Server.

You may want to use developer tools included with WebLogic Server for creating and configuring Web applications. See Web Application Developer Tools.

Step One: Create the Enterprise Application Wrapper

Create a directory for your root EAR file:
```
\src\myEAR\
```
Set your environment as follows:
- On Windows, execute the setWLSEnv.cmd command, located in the directory WL_HOME\server\bin\, where WL_HOME is the top-level directory in which WebLogic Server is installed.
- On UNIX, execute the setWLSEnv.sh command, located in the directory WL_HOME/server/bin/, where WL_HOME is the top-level directory in which WebLogic Server is installed.
Note:

On UNIX operating systems, the setWLSEnv.sh command does not set the environment variables in all command shells. Oracle recommends that you execute this command using the Korn shell or bash shell.
Package your enterprise application in the \src\myEAR\ directory as follows:
1. Place the enterprise applications descriptors (application.xml and weblogic-application.xml) in the META-INF\ directory. See Enterprise Application Deployment Descriptors in Developing Applications for Oracle WebLogic Server.
2. Edit the deployment descriptors as needed to fine-tune the behavior of your enterprise application. See Web Application Developer Tools.
3. Place the enterprise application .jar files in:
```
\src\myEAR\APP-INF\lib\
```

Step Two: Create the Web Application

Create a directory for your Web application in the root of your EAR file:
```
\src\myEAR\myWebApp
```
Package your Web application in the \src\myEAR\myWebApp\ directory as follows:
1. Place the Web application descriptors (web.xml and weblogic.xml) in the \src\myEAR\myWebApp\WEB-INF\ directory. See weblogic.xml Deployment Descriptor Elements.
2. Edit the deployment descriptors as needed to fine-tune the behavior of your enterprise application. See Web Application Developer Tools.
3. Place all HTML files, JSPs, images and any other files referenced by the Web application pages in the root of the Web application:
```
\src\myEAR\myWebApp\images\myimage.jpg
\src\myEAR\myWebApp\login.jsp
\src\myEAR\myWebApp\index.html
```
4. Place your Web application Java source files (servlets, tag libs, other classes referenced by servlets or tag libs) in:
```
\src\myEAR\myWebApp\WEB-INF\src\
```

Step Three: Creating the build.xml File

Once you have set up your directory structure, you create the build.xml file using the weblogic.BuildXMLGen utility.

Step Four: Execute the Split Development Directory Structure Ant Tasks

Execute the wlcompile Ant task to invoke the javac compiler. This compiles your Web application Java components into an output directory: /build/myEAR/WEB-INF/classes.
Execute wlappc Ant task to invoke the appc compiler. This compiles any JSPs and container-specific EJB classes for deployment.
Execute the wldeploy Ant task to deploy your Web application as part of an archived or exploded EAR to WebLogic Server.
If this is a production environment (rather than development), execute the wlpackage Ant task to package your Web application as part of an archived or exploded EAR.

Note:

The wlpackage Ant task places compiled versions of your Java source files in the build directory. For example: /build/myEAR/myWebApp/classes.

Configuring How a Client Accesses a Web Application

You construct the URL that a client uses to access a Web application using a specific pattern.

http://hoststring/ContextPath/servletPath/pathInfo

Where

hoststring is either a host name that is mapped to a virtual host or hostname:portNumber.
ContextPath is the name of your Web application.
servletPath is a servlet that is mapped to the servletPath.
pathInfo is the remaining portion of the URL, typically a file name.

If you are using virtual hosting, you can substitute the virtual host name for the hoststring portion of the URL.

Configuring Virtual Hosts for Web Applications

WebLogic Server supports two methods for configuring virtual hosts for Web applications.

Configuring a Channel-based Virtual Host

The following is an example of how to configure a channel-based virtual host:

<VirtualHost Name="channel1vh" NetworkAccessPoint="Channel1" Targets="myserver"/> 
<VirtualHost Name="channel2vh" NetworkAccessPoint="Channel2" Targets="myserver"/>

Where Channel1 and Channel2 are the names of NetworkAccessPoint configured in the config.xml file. NetworkAccessPoint represents the dedicated server channel name for which the virtual host serves HTTP requests. If the NetworkAccessPoint for a given HTTP request does not match the NetworkAccessPoint of any virtual host, the incoming HOST header is matched with the VirtualHostNames in order to resolve the correct virtual host. If an incoming request does not match a virtual host, the request will be served by the default Web server.

Configuring a Host-based Virtual Host

The following is an example of how to configure a host-based virtual host:

<VirtualHost Name="cokevh" Targets="myserver" VirtualHostNames="coke"/> 
<VirtualHost Name="pepsivh" Targets="myserver" VirtualHostNames="pepsi"/>

Targeting Web Applications to Virtual Hosts

A Web application component can be targeted to servers and virtual hosts using the WebLogic Server Administration Console.

If you are migrating from previous versions of WebLogic Server, note that in the config.xml file, all Web application targets must be specified in the targets attribute. The targets attribute has replaced the virtual hosts attribute and a virtual host cannot have the same name as a server or cluster in the same domain. The following is an example of how to target a Web application to a virtual host:

<AppDeployment name="test-app" Sourcepath="/myapps/test-app.ear">
   <SubDeployment Name="test-webapp1.war" Targets="virutalhost-1"/>
   <SubDeployment Name="test-webapp2.war" Targets="virtualhost-2"/>
   ...
</AppDeployment>

Loading Servlets, Context Listeners, and Filters

Servlets, context listeners, and filters are loaded and destroyed in a certain order:

Order of loading:

Context listeners
Filters
Servlets

Order of destruction:

Servlets
Filters
Context listeners

Servlets and filters are loaded in the same order they are defined in the web.xml file and unloaded in reverse order. Context listeners are loaded in the following order:

All context listeners in the web.xml file in the order as specified in the file
Packaged JAR files containing tag library descriptors
Tag library descriptors in the WEB-INF directory

Shared Java EE Web Application Libraries

A Java EE Web application library is a standalone Web application module registered with the Java EE application container upon deployment. With WebLogic Server, multiple Web applications can easily share a single Web application module or collection of modules.

A Web application may reference one or more Web application libraries, but cannot reference other library types (EJBs, EAR files, plain JAR files). Web application libraries are Web application modules deployed as libraries. They are referenced from the weblogic.xml file using the same syntax that is used to reference application libraries in the weblogic-application.xml file, except that the <context-root> element is ignored.

At deployment time, the classpath of each referenced library is appended to the Web application's classpath. Therefore, the search for all resources and classes occurs first in the original Web application and then in the referenced library.

The deployment tools, appc, wlcompile, and BuildXMLGen support libraries at the Web application level in the same way they support libraries at the application level. For more information about shared Java EE libraries and their deployment, see Creating Shared Java EE Libraries and Optional Packages in Developing Applications for Oracle WebLogic Server.

Enabling GZIP Compression for Web Applications

The WebLogic Server Web container supports HTTP content-encoding GZIP compression, which is part of HTTP/1.1. With GZIP compression, you can reduce the size of the data that a Web browser has to download, improving network bandwidth.

For general information about content-encoding and GZIP compression, see the Hypertext Transfer Protocol HTTP/1.1 Specification.

You can enable and configure content-encoding GZIP compression at the domain level or Web application level.

To set domain-wide values for GZIP compression support, use WLST to configure the following attributes of the GzipCompressionMBean under the WebAppContainerMBean:

Table 2-1 Domain-Level GZIP Compression Attributes

Attribute Description Default Value

Attribute	Description	Default Value
`GzipCompressionEnabled`	Enables GZIP compression for all Web applications in the domain.	`false`
`GzipCompressionMinCompressionContentLength`	Specifies the minimum file size to trigger compression in Web applications. This attribute allows you to bypass small-sized resources where compression would not yield a great return but use unnecessary CPU.	`2048`
`GzipCompressionContentType`	Specifies the type of content to be included compression.	`"text/html, text/xml, text/plain"`

GzipCompressionEnabled

Enables GZIP compression for all Web applications in the domain.

false

GzipCompressionMinCompressionContentLength

Specifies the minimum file size to trigger compression in Web applications.

This attribute allows you to bypass small-sized resources where compression would not yield a great return but use unnecessary CPU.

2048

GzipCompressionContentType

Specifies the type of content to be included compression.

"text/html, text/xml, text/plain"

To configure GZIP compression for a specific Web application, use the gzip-compression element in the weblogic.xml deployment descriptor container-descriptor element. See gzip-compression.

Application-level values override domain-level values. Therefore, any gzip-compression values set in weblogic.xml take precedence over domain-wide values set in the GzipCompressionMBean or default values.

WebLogic Server determines the GZIP compression attribute value to use based on the following override hierarchy:

If you do not configure GZIP compression in the individual Web application weblogic.xml file or in the domain-wide GzipCompressionMBean, then the domain default value is used.
If you configure GZIP compression in the domain-wide GzipCompressionMBean, then the MBean value overrides the default value. The GzipCompressionMBeanvalue is used.
If you configure GZIP compression in the individual Web application weblogic.xml file, then the weblogic.xml file overrides the GzipCompressionMBean value and the default value. The Web application weblogic.xml value is used.

You can track compression statistics, such as CPUs used, original content length, GZIP content length, and the compression ratio, by enabling the HTTPDebugLoggerdebug flag, which tracks information about these statistics in existing server log files. If HTTPDebugLogger is not enabled, these statistics are not tracked. To enableHTTPDebugLogger, set -Dweblogic.debug.DebugHttp=true in JAVA_OPTIONS in the server start script.