Servlets and JSPs

WebLogic supports HTTP servlets as defined in the Servlet 2.3 specification, as well as JSP pages and tag extensions as defined in the JSP 1.2 specification. Typically, you will use servlets alongside JSPs to build a web application. WebLogic provides a number of useful additions to standard servlet and JSP configuration. For example, you can assign custom execute queues to critical servlets, and install servlets to serve static files and act as a CGI gateway.

2.3.1 Configuring a Custom Execute Queue

By default, all J2EE applications (except JMS resources) share the same pool of server threads for their operation. This includes the servlets and JSPs that rely on the default execute queue configured for a particular WebLogic instance. However, WebLogic also lets you assign a custom execute queue that is dedicated to an individual servlet (or JSP). In this way, you can ensure that a dedicated pool of threads is always available for a particular servlet and that it doesn't need to compete with other services for a free server thread. Execute queues are explained is more detail in Chapter 15.

To assign an execute queue to a servlet, you need to modify the weblogic.xml descriptor file to include a dispatch-policy element for the servlet. The value of this element should match the name of a preconfigured execute queue. Here is an example:

FooServlet system system MyCustomExecuteQ

In this way, you can configure each servlet with its own execute queue, or perhaps even force multiple servlets to share the same execute queue.

2.3.2 Threading Issues

When using multithreaded servlets, you must make adequate provisions for concurrent access within the service methods. Your servlet code needs to guard against sharing violations on access to shared resources and member variables. That said, wherever possible, avoid synchronization because it blocks other servlet threads until the current thread has completed. Limit sharing across threads by defining variables within the scope of the service methods. If you are accessing external resources such as databases, JMS destinations, etc., you need to synchronize on the class level, or whenever possible, encapsulate your work in a transaction.

2.3.2.1 Single-threaded servlets

An instance of a servlet that implements the SingleThreadModel interface is guaranteed never to be invoked concurrently by multiple threads. WebLogic creates multiple instances of a single-threaded servlet so that it can serve multiple client requests simultaneously. This pool of servlet instances is created initially when the servlet is first requested. You can use the single-threaded-servlet-pool-size element in the weblogic.xml file to specify the initial number of servlet instances that are created. Typically, you will set the value of this attribute to the average number of concurrent requests that the servlet is likely to receive. In WebLogic 8.1, you can configure this setting from the Administration Console. Select the web application in the left frame, and then, from the Configuration/Descriptor tab, supply a value for the Single Threaded Servlet Pool Size setting. By default, WebLogic initializes the pool with five servlet instances.

Because WebLogic creates a pool of servlet instances (one for each thread), you effectively multiply the memory requirements of the servlet, at least for all the nonstatic attributes of the servlet. If you have declared shared class variables (for instance, a static attribute), even though it will be accessed in a single-threaded manner, there could be many such single-threaded instances potentially accessing the same resource. You must be careful to ensure that you avoid all synchronization issues.

2.3.3 Custom URL Pattern Matching

The servlet-mapping declaration in the web.xml deployment descriptor allows you to specify the URL pattern that must be matched to invoke a particular servlet. WebLogic provides an extension to the URL matching mechanism and allows you to plug in a richer pattern matcher for instance, a matching scheme that goes beyond the use of just the / and * metacharacters. To configure this scheme, you must use the url-match-map element in the weblogic.xml descriptor file to specify the fully qualified name of a class that provides the actual logic for custom URL matching:

com.oreilly.wlguide.servlets.OReillyURLMatchMap

This class must implement the following interface, found in the weblogic.servlet.utils package:

public interface URLMapping { public void put(String pattern, Object value); public Object get(String uri); public void remove(String pattern) public void setDefault(Object defaultObject); public Object getDefault( ); public void setCaseInsensitive(boolean ci); public boolean isCaseInsensitive( ); public int size( ); public Object[] values( ); public String[] keys( ); }

By default, WebLogic Server uses the J2EE-standard URL pattern-matching scheme. This is set up because the value of the url-match-map element defaults to weblogic.servlet.utils.URLMatchMap.

2.3.4 Configuring JSPs

Just as you can when deploying servlets, you can use the servlet element in the standard web.xml deployment descriptor to register a JSP page:

home home.jsp home /home

Here, a request to the URL /home will cause /home.jsp to be invoked. In Chapter 18, you'll see how a similar mapping enables XSLT conversion from within a JSP. By registering a JSP as a servlet in this way, you can do the following:

• Specify the load order of JSP pages
• Define any initialization parameters for those pages
• Restrict access by applying security roles to JSP pages

The jsp-descriptor element in the weblogic.xml descriptor file allows you to specify additional settings for JSP compilation. Each JSP configuration parameter is defined as a name/value pair within a jsp-param subelement. Here is an example of how to configure the translator to retain generated Java files:

keepgenerated true

Table 2-2 provides a complete list of JSP configuration parameters that may be defined in the jsp-descriptor element. Remember, you need to define a separate jsp-param element for each configuration parameter.

You can set the "JSP page check seconds," "Keep Generated," "verbose," "debug line numbers," and "compiler command" settings using the Administration Console. These settings can be found on the Configuration/Descriptor tab of a web application.

By default, WebLogic automatically checks for modifications to JSP pages in a web application, and automatically recompiles a JSP if it is invoked after it has been modified. By setting the pageCheckSeconds configuration parameter to -1, you avoid the overhead WebLogic incurs when it needs to monitor changes to JSP source files that belong to the web application. In this scenario, the JSPs will be updated only when the entire web application is redeployed. This is particularly useful in production deployments in which you typically want compilation to occur only under the explicit control of a deployer. We have found that this setting does affect performance.

Note that WebLogic places all compiled JSPs into an internally generated directory. As a new directory is created every time the server is started, you will lose all of the compiled JSPs. If you want to avoid this and retain the compiled JSPs across server startups, specify a workingDir to use.