Configuring Web Applications

The configuration for a web application deployed on WebLogic is spread across the application's deployment descriptors and the server configuration file. For instance:

• The session timeout for the web application can be configured using the session-timeout element within the standard web.xml deployment descriptor.
• The JSP compilation parameters for a web application are defined in the WebLogic-specific weblogic.xml deployment descriptor.
• The staging mode setting, which determines how a web application is deployed, can be found in the server's config.xml file.

The easiest approach to editing the deployment descriptors is to use either the Administration Console or WebLogic Builder. The following sections examine WebLogic-specific configuration settings related to web applications.

2.2.1 Context Root

A web application is rooted at a specific path within the web server, called the context root. For example, if the context root for a web application is set to here, you could access it by using a URL of the form http://server:port/here/index.html. If you do not explicitly set a context root for the web application, its default value depends on how the web application has been packaged:

• If the web application is deployed in the exploded format, its default context root is the name of the folder that holds the contents of the web application.
• If the contents of the web application have been packaged as a web archive, its default context root is the name of the web archive itself. An example of this is if you deploy the web application myWar.war to WebLogic, you can invoke a resource say, index.html using the URL http://server:port/myWar/index.html.

There are two ways to configure the context root for a web application:

• If it is deployed as a standalone application, you can set the context-root element within the weblogic.xml descriptor for the web application:

   ourwebapp
  

• If it exists as a J2EE module within an enterprise application, you can configure the context-root element in the standard application.xml deployment descriptor for the enterprise application:

   
   mywebapp
   ourwebapp
   
  

As shown in Chapter 3, setting the default web application for the web server or virtual host means that the context path can be omitted altogether from URLs that access the web application.

2.2.2 Directory Listings

If a client makes a partial request that resolves to a directory that doesn't contain any of the pages specified in the list of welcome files, WebLogic Server returns a 404 response. However, if you have checked the Index Directories flag for the web application, WebLogic then will return a directory listing to the client instead. By default, if no welcome files are defined, WebLogic looks for the following files in order and serves the first one it finds: index.html, index.htm, and index.jsp.

The Index Directory Enabled flag can be reached by selecting the web application in the Administration Console and moving to the Configuration/Descriptor tab. If you have enabled this option, you also can specify the sort order of the directory listing. This can be done only in the weblogic.xml descriptor file. Here is how to enable directory listings and specify a sort order:

 true
 SIZE

In WebLogic 7.0, this option is available in the Configuration/Files tab of a web application. The valid sort orders are SIZE, NAME, or LAST_MODIFIED.

2.2.3 Serving Static Files

By default, WebLogic uses an internal servlet, weblogic.servlet.FileServlet, to serve requests for static resources in a web application. You can modify this default behavior by mapping a custom servlet to the URL pattern /. Your custom servlet will then respond to requests for all files except those with the extension .htm or .html, which still will be handled by FileServlet. If your custom servlet must also handle requests for HTML files, you need to explicitly associate the HTML files with your servlet.

The following portion from the web.xml descriptor file shows how to override the default FileServlet for all web resources:

 MyServlet 
 / 



 MyServlet 
 *.htm* 

2.2.4 Enabling CGI Scripts

WebLogic can be configured so that web applications can support Common Gateway Interface (CGI) scripts. Your WebLogic distribution is shipped with a CGI servlet, weblogic.servlet.CGIServlet, which provides a gateway to such scripts. Example 2-2 shows how you can configure the CGI servlet to invoke shell scripts.

Example 2-2. Enabling CGI for a web application

 CGIServlet
 weblogic.servlet.CGIServlet
 
 cgiDir
 scripts
 
 
 *.sh
 d:cygwininash
 

...

 CGIServlet
 /cgi/*

CGIServlet requires the following initialization parameters:

cgiDir

This parameter specifies a list of the names of directories containing your CGI scripts. For Unix platforms, you must remember to use a colon (:) to separate multiple folder names. By default, WebLogic looks for scripts in the cgi-bin directory under the document root for the web application.

Extension mappings

These parameters let you map a file extension to an interpreter or an executable that can run the scripts. You can define any number of these mappings, mapping different file extensions to either the same (or different) interpreter.

If you have configured the CGI servlet for a web application as shown in Example 2-2, you can invoke the script helloworld.sh by simply navigating to the URL http://server:port/webapp/cgi/helloworld.sh. You must place the helloworld.sh file into the scripts directory of your web application.

Ensure that the CGI script returns an exit code of 0 when it ends successfully. Otherwise, WebLogic concludes the script has failed, and will report a server error (500) to the browser.

 

2.2.5 Reloading Files

WebLogic automatically picks up any changes to static content within a web application in the development mode. In fact, WebLogic is able to detect changes to servlets, filters, JSP tag implementation classes, and any classes found under the WEB-INF/classes folder. This is possible because WebLogic regularly inspects the filesystem for changes in web resources. You can adjust the frequency with which WebLogic looks at the filesystem for changes in the contents of the web application. Select the web application from under the Deployments/Web Application Modules node in the left pane of the Administration Console. Then, from the Configuration/Settings tab in the right pane, adjust the value of the Servlet Reload Check Secs setting. WebLogic 7.0 users can find this in the Configuration/Files tab.

Changes to JSP files also are picked up provided you've set a nonnegative value for the pageCheckSeconds element in the weblogic.xml descriptor for the web application.

2.2.6 Resources References

The J2EE specification defines how to configure the naming environment, which allows web applications to easily access resources and external information without actually knowing how that information is named or organized. Depending on the resource, you will use one or more of the following elements in the standard web.xml descriptor: the env-entry, ejb-ref, ejb-local-ref, resource-ref, security-role-ref, and resource-env-ref elements. At runtime, you can use these elements to access objects registered in the JNDI namespace for the web container. The weblogic.xml descriptor file must be configured to map these references to real resources that have been deployed to the server. For instance, suppose you've configured WebLogic with a data source, which you've placed in the JNDI with its name set to myDataSource. Now you can define the following entries in the deployment descriptors for the web application:

 jdbc/myds
 javax.sql.DataSource
 Container




 jdbc/myds
 myDataSource

Then, you can access this data source using the resource reference jdbc/myds as follows:

javax.sql.DataSource ds = 
 (javax.sql.DataSource) ctx.lookup("java:comp/env/jdbc/myds");

Note that your Java code doesn't have to explicitly reference the global JNDI name myDataSource instead, you can use the alias jdbc/myds.

Similarly, suppose you've defined the following entries in the deployment descriptors for a web application:

 ejb/foohome
 Session
 com.foo.bar.FooHome
 com.foo.bar.Foo




 ejb/foohome
 FooHome

Here the standard web.xml descriptor file declares an EJB reference to a session bean, and the weblogic.xml descriptor file maps the EJB reference to its actual JNDI name. You then can access the session bean registered in the global JNDI tree under the name FooHome using the EJB reference ejb/foohome as follows:

Object home = ctx.lookup("java:comp/env/ejb/foohome");
FooHome fh = (FooHome) PortableRemoteObject.narrow(home, FooHome.class);

Again, we have not used the session EJB's actual JNDI name within our code. Instead we used its alias ejb/foohome.

The WebLogic Builder tool provides an easy way to declare these references.

2.2.7 Response Caching

WebLogic supplies a cache servlet filter that permits page-level caching of responses. Setting up such a filter is very easy. Example 2-3 establishes a cache filter that works on all files ending with a .html extension, and configures the cache to be application-wide.

Example 2-3. A cache filter for all HTML files in a web application

 HTML
 weblogic.cache.filter.CacheFilter
 
 scope
 application
 



 HTML
 *.html

The cache filter automatically caches the Content-Type and Last-Modified response header fields. A cached page is served only if the If-Modified-Since request header is more recent than the Last-Modified response header otherwise, the filter sends back an SC_NOT_MODIFIED(302) status with no content. The filter can be configured in various ways depending on the values of the initialization parameters. You can define the following parameters:

name

Specifies the name for the cache; defaults to the request URI.

timeout

Determines the amount of time to wait between cache updates. The default unit of time is seconds, but this can be changed by specifying a value followed by ms (milliseconds), s (seconds), m (minutes), h (hours), or d (days). Note that the value of an item is refreshed only when it is requested and timed out, not if it is only timed out.

scope

Determines whether the scope of the cache is for the request, session, application, or cluster. The default scope is application.

size

Determines the number of different unique key values that are cached. It defaults to infinity (limited by memory because of the soft reference implementation).

key

Ordinarily the key will be the URL requested. You can use this attribute to specify a comma-separated list of additional keys. The value of this attribute will be the name of the variable whose value you wish to use as a key into the cache. You additionally can specify a scope by prepending the scope to the key. For example, a value of application.mykey implies the target resource will carry an additional key i.e., the value of the attribute mykey in the context for the web application. If no scope is prepended, WebLogic will search through the scopes in the order shown earlier.

Cache filters are extremely useful; they provide a reusable and configurable way for caching various parts of your web application without requiring any code changes. When configured properly, cache filters can provide a significant performance boost to your web application. The next chapter shows how WebLogic's JSP cache tags support a slightly richer version of this caching behavior. It also provides more examples on the use of keys.