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.

Table 2-2. JSP configuration parameters

Parameter name	Description	Default
compileCommand	This specifies the full pathname of the standard Java compiler used to compile .java files generated from a JSP. By default, the compiler uses javac (from your PATH environment variable) or the compiler set in the server configuration for WebLogic Server.	javac
compileFlags	This parameter specifies one or more flags to be used by the standard Java compiler. Multiple flags should be enclosed in quotes: compileFlags "-g -v"	none
debug	If this parameter is set to true, the JSP compiler adds JSP line numbers to the generated source files (as an aid to debugging).	false
encoding	This parameter defines the default character set used by JSPs. If no value is set, the character encoding for your platform becomes the default encoding for all JSPs. You can override this setting by declaring a contentType page directive in your JSP: <%@ page contentType="text/html; charset=ISO-8859-1" %>	default platform encoding
keepgenerated	This tells the JSP compiler to not delete the intermediate .java source file once it has compiled successfully.	false
noTryBlocks	If this parameter's value is set to true, try/catch blocks are not generated for JSPs that use nonempty tags. Because tag library descriptor (TLD) files do not allow you to specify valid tag nestings, the compiler cannot enforce how custom tags ought to be nested. This means you could accidentally nest a custom tag within another, and erroneously rely on a "dependency" that may not occur at runtime (e.g., a shared object with page scope may be unavailable to an inner tag). To avoid any nasty consequences, the JSP compiler emits try/catch blocks around each tag. You could avoid try/catch blocks altogether by setting this parameter to true, but it may mean you have to deal with more obscure runtime errors if you use the tags incorrectly.	false
packagePrefix	This sets the package prefix for generated HTTP servlets.	jsp_servlet
superclass	This parameter specifies the super class for the generated servlet. The supplied value must be a subclass of javax.servlet.http.HttpServlet or javax.servlet.GenericServlet.	weblogic. servlet.jsp. JspBase
pageCheckSeconds	This specifies the interval (in seconds) at which WebLogic Server checks to see whether the JSP files have been modified and need recompiling (WebLogic also checks dependencies and reloads them as required). If this parameter's value is set to 0, pages are checked on every request; if it is set to -1, page checking and recompilation are disabled.	1
precompile	If this parameter's value is set to true, WebLogic Server automatically precompiles all JSP resources when the web application is deployed (or redeployed).	false
verbose	If this parameter's value is set to true, debugging information is printed out to the browser, console, and WebLogic Server log files.	true
workingDir	This specifies the directory where WebLogic places compiled JSP classes (and intermediate Java source files, if keepgenerated is true).	A directory generated internally by WebLogic Server
printNulls	Setting this parameter to true tells the compiler to treat null values in JSP expressions as empty strings.	false

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.