Key OracleJSP Configuration Issues

This section covers important effects of how you set key page directive parameters and OracleJSP configuration parameters. The discussion focuses on JSP page optimization, and classpath and class loader issues. The following topics are covered:

• Optimization of JSP Execution

• Classpath and Class Loader Issues (Non-OSE Only)

Optimization of JSP Execution

There are settings you can consider to optimize JSP performance, including the following:

• Unbuffering a JSP Page

• Not Checking for Retranslation (Non-OSE Only) ("developer mode")

• Not Using an HTTP Session

Unbuffering a JSP Page

By default, a JSP page uses an area of memory known as a page buffer. This buffer (8KB by default) is required if the page uses dynamic NLS content type settings, forwards, or error pages. If it does not use any of these features, you can disable the buffer in a page directive:

<%@ page buffer="none" %>

This will improve the performance of the page by reducing memory usage and saving an output step (output goes straight to the browser instead of going through the buffer first).

Not Checking for Retranslation (Non-OSE Only)

When OracleJSP executes a JSP page, by default it will check whether a page implementation class already exists, compare the .class file timestamp against the .jsp source file timestamp, and retranslate the page if the .class file is older.

If comparing timestamps is unnecessary (as is the case in a typical deployment environment, where source code will not change), you can avoid the timestamp comparison by disabling the OracleJSP developer_mode flag (developer_mode=false).

The default setting is true. For information about how to set this flag in the Apache/JServ, JSWDK, and Tomcat environments, see "OracleJSP Configuration Parameter Settings".

Not Using an HTTP Session

If a JSP page does not need an HTTP session (essentially, does not need to store or retrieve session attributes), then you can avoid using a session through the following page directive:

<%@ page session="false" %>

This will improve the performance of the page by eliminating the overhead of session creation or retrieval.

Note that although servlets by default do not use a session, JSP pages by default do use a session. For background information, see "Servlet Sessions".)

Classpath and Class Loader Issues (Non-OSE Only)

OracleJSP uses its own classpath, distinct from the Web server classpath, and by default uses its own class loader to load classes from this classpath. This has significant advantages and disadvantages.

The OracleJSP classpath combines the following elements:

• the OracleJSP default classpath

• additional classpaths you specify in the OracleJSP classpath configuration parameter

If there are classes you want loaded by the OracleJSP class loader instead of the system class loader, use the OracleJSP classpath configuration parameter, or place the classes in the OracleJSP default classpath. See "Advantages and Disadvantages of the OracleJSP Class Loader" for related discussion.

OracleJSP Default Classpath

Oracle JSP defines standard locations on the Web server for locating .class files and .jar files for classes (such as JavaBeans) that it requires. OracleJSP will find files in these locations without any Web server classpath configuration.

These locations are as follows and are relative to the application root:

/WEB-INF/classes 
/WEB-INF/lib 
/_pages

Important: If you want classes in the WEB-INF directories to be loaded by the system class loader instead of the OracleJSP class loader, place the classes somewhere in the Web server classpath as well. The system class loader takes priority--any class that is placed in both classpaths will always be loaded by the system class loader.

The classes directory is for individual Java .class files. These classes should be stored in subdirectories under the classes directory, according to Java package naming conventions.

For example, consider a JavaBean called LottoBean whose code defines it to be in the oracle.jsp.sample.lottery package. OracleJSP will look for LottoBean.class in the following location relative to the application root:

/WEB-INF/classes/oracle/jsp/sample/lottery/LottoBean.class

The lib directory is for .jar files. Because Java package structure is specified in the .jar file structure, the .jar files are all directly in the lib directory (not in subdirectories).

As an example, LottoBean.class might be stored in lottery.jar, located as follows relative to the application root:

/WEB-INF/lib/lottery.jar

The application root directory can be located in any of the following locations (as applicable, depending on your Web server and servlet environment), listed in the order they are searched:

• the Web server directory this application is mapped to

• the Web server document root directory

• the directory containing the globals.jsa file (where applicable, typically in a servlet 2.0 environment)

  Notes: Some Web servers, particularly those supporting the servlet 2.0 specification, do not offer full application support such as complete servlet context functionality. In this case, or when application mapping is not used, the default application is the server itself, and the application root is the Web server document root. For older servlet environments, the globals.jsa file is an Oracle extension that can be used as an application marker to establish an application root. See "OracleJSP Application and Session Support for Servlet 2.0".

OracleJSP classpath Configuration Parameter

Use the OracleJSP classpath configuration parameter to add to the OracleJSP classpath.

For more information about this parameter, see "OracleJSP Configuration Parameters (Non-OSE)".

For information about how to set this parameter in the Apache/JServ, JSWDK, and Tomcat environments, see "OracleJSP Configuration Parameter Settings".

Advantages and Disadvantages of the OracleJSP Class Loader

Using the OracleJSP class loader results in the following advantages and disadvantages:

• limited access to OracleJSP-loaded classes from classes loaded by any other class loader

  When a class is loaded by the OracleJSP class loader , its definition exists in the OracleJSP class loader only. Classes loaded by the system class loader or any other class loader, including any servlets, would have only limited access. The classes loaded by another class loader could not cast the OracleJSP-loaded class or call methods on it. This may be desirable or undesirable, depending on your situation.

• automatic class reloading

  By default, the OracleJSP class loader will automatically reload a class in the OracleJSP classpath whenever the class file or JAR file has been modified since it was last loaded. (For a JSP page, for example, this can happen as a result of dynamic retranslation, which occurs by default if the .jsp source file for a page has a more recent timestamp than its corresponding page implementation .class file).

  This is usually only advantageous in a development environment. In a typical deployment environment, the source, class, and JAR files will not change, and it is inefficient to check them for changes.

  See "Dynamic Class Reloading" for more information.

It follows that in a deployment environment, you will typically not want to use the OracleJSP classpath. By default, the classpath parameter is empty.

---