Oracle JavaServer Pages Developer's Guide and Reference Release 8.1.7 Part Number A83726-01 |
|
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:
There are settings you can consider to optimize JSP performance, including the following:
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).
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".
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".)
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:
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.
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
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:
globals.jsa
file (where applicable, typically in a servlet 2.0 environment)
Notes:
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".
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".
Using the OracleJSP class loader results in the following advantages and disadvantages:
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.
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.
|
![]() Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|