Skip Headers

Oracle9i Support for JavaServer Pages Reference
Release 2 (9.2)
Part Number A96657-01
Go To Documentation Library
Home		 Go To Product List
Book List		 Go To Table Of Contents
Contents		 Go To Index
Index
Master Index
Feedback

Go to previous page Go to next page

4
Key Considerations

This chapter discusses important programming, configurational, and runtime considerations in developing a JSP application. The following topics are covered:

General JSP Programming Strategies, Tips, and Traps

This section discusses issues you should consider when programming JSP pages that will run in the Oracle JSP container, regardless of the particular target environment. The following assortment of topics are covered:

JavaBeans Versus Scriptlets

The section "Separation of Business Logic from Page Presentation: Calling JavaBeans" describes a key advantage of JavaServer Pages technology: Java code containing the business logic and determining the dynamic content can be separated from the HTML code containing the request processing, presentation logic, and static content. This separation allows HTML experts to focus on presentation logic in the JSP page itself, while Java experts focus on business logic in JavaBeans that are called from the JSP page.

A typical JSP page will have only brief snippets of Java code, usually for Java functionality for request processing or presentation. The sample page in "JSP Starter Sample for Data Access", although illustrative, is probably not an ideal design. Data access, such as in the runQuery() method in the sample, is usually more appropriate in a JavaBean. However, the formatResult() method in the sample, which formats the output, is more appropriate for the JSP page itself.

Use of JDBC Performance Enhancement Features

You can use the following performance enhancement features, supported through Oracle JDBC extensions, in JSP applications executed by the Oracle JSP container:

Most of these performance features are supported by the Oracle ConnBean and ConnCacheBean data-access JavaBeans (but not by DBBean). These beans are described in the Oracle9iAS Containers for J2EE JSP Tag Libraries and Utilities Reference.

Database Connection Caching

Creating a new database connection is an expensive operation that you should avoid whenever possible. Instead, use a cache of database connections. A JSP application can get a logical connection from a pre-existing pool of physical connections, and return the connection to the pool when done.

You can create a connection pool at any one of the four JSP scopes--application, session, page, or request. It is most efficient to use the maximum possible scope--application scope if that is permitted by the Web server, or session scope if not.

The Oracle JDBC connection caching scheme, built upon standard connection pooling as specified in the JDBC 2.0 standard extensions, is implemented in the ConnCacheBean data-access JavaBean provided with Oracle9i. This is probably how most JSP developers will use connection caching. This bean is described in the Oracle9iAS Containers for J2EE JSP Tag Libraries and Utilities Reference.

It is also possible to use the Oracle JDBC OracleConnectionCacheImpl class directly, as though it were a JavaBean, as in the following example (although all OracleConnectionCacheImpl functionality is available through ConnCacheBean).

<jsp:useBean id="occi" class="oracle.jdbc.pool.OracleConnectionCacheImpl"
             scope="session" />

The same properties are available in OracleConnectionCacheImpl as in ConnCacheBean. They can be set either through jsp:setProperty statements or directly through the class setter methods.

For information about the Oracle JDBC connection caching scheme and the OracleConnectionCacheImpl class, see the Oracle9i JDBC Developer's Guide and Reference.

JDBC Statement Caching

Statement caching, an Oracle JDBC extension, improves performance by caching executable statements that are used repeatedly within a single physical connection, such as in a loop or in a method that is called repeatedly. When a statement is cached, the statement does not have to be re-parsed, the statement object does not have to be recreated, and parameter size definitions do not have to be recalculated each time the statement is executed.

The Oracle JDBC statement caching scheme is implemented in the ConnBean and ConnCacheBean data-access JavaBeans that are provided with Oracle9i. Each of these beans has a stmtCacheSize property that can be set through a jsp:setProperty statement or the setStmtCacheSize() method of the bean. The beans are described in the Oracle9iAS Containers for J2EE JSP Tag Libraries and Utilities Reference.

Statement caching is also available directly through the Oracle JDBC OracleConnection and OracleConnectionCacheImpl classes. For information about the Oracle JDBC statement caching scheme and the OracleConnection and OracleConnectionCacheImpl classes, see the Oracle9i JDBC Developer's Guide and Reference.

Important:

Statements can be cached only within a single physical connection. When you enable statement caching for a connection cache, statements can be cached across multiple logical connection objects from a single pooled connection object, but not across multiple pooled connection objects.

Update Batching

The Oracle JDBC update batching feature associates a batch value (limit) with each prepared statement object. With update batching, instead of the JDBC driver executing a prepared statement each time its "execute" method is called, the driver adds the statement to a batch of accumulated execution requests. The driver will pass all the operations to the database for execution once the batch value is reached. For example, if the batch value is 10, then each batch of ten operations will be sent to the database and processed in one trip.

The Oracle JSP container supports Oracle JDBC update batching directly, through the executeBatch property of the ConnBean data-access JavaBean. You can set this property through a jsp:setProperty statement or through the setter method of the bean. If you use ConnCacheBean instead, you can enable update batching through Oracle JDBC functionality in the connection and statement objects you create. These beans are described in the Oracle9iAS Containers for J2EE JSP Tag Libraries and Utilities Reference.

For more information about Oracle JDBC update batching, see the Oracle9i JDBC Developer's Guide and Reference.

Row Prefetching

The Oracle JDBC row prefetching feature allows you to set the number of rows to prefetch into the client during each trip to the database while a result set is being populated during a query, reducing the number of round trips to the server.

The Oracle JSP container supports Oracle JDBC row prefetching directly, through the preFetch property of the ConnBean data-access JavaBean. You can set this property through a jsp:setProperty statement or through the setter method of the bean. If you use ConnCacheBean instead, you can enable row prefetching through Oracle JDBC functionality in the connection and statement objects you create. These beans are described in the Oracle9iAS Containers for J2EE JSP Tag Libraries and Utilities Reference.

For more information about Oracle JDBC row prefetching, see the Oracle9i JDBC Developer's Guide and Reference.

Rowset Caching

A cached rowset provides a disconnected, serializable, and scrollable container for retrieved data. This feature is useful for small sets of data that do not change often, particularly when the client requires frequent or continued access to the information. By contrast, using a normal result set requires the underlying connection and other resources to be held. Be aware, however, that large cached rowsets consume a lot of memory on the client.

In Oracle9i, Oracle JDBC provides a cached rowset implementation. If you are using an Oracle JDBC driver, use code inside a JSP page to create and populate a cached rowset as follows:

CachedRowSet crs = new CachedRowSet();
crs.populate(rset); // rset is a previously created JDBC ResultSet object.

Once the rowset is populated, the connection and statement objects used in obtaining the original result set can be closed.

For more information about Oracle JDBC cached rowsets, see the Oracle9i JDBC Developer's Guide and Reference.

Static Includes Versus Dynamic Includes

The include directive, described in "Directives", makes a copy of the included page and copies it into a JSP page (the "including page") during translation. This is known as a static include (or translate-time include) and uses the following syntax:

<%@ include file="/jsp/userinfopage.jsp" %>

The jsp:include action, described in "JSP Actions and the <jsp: > Tag Set", dynamically includes output from the included page within the output of the including page, during runtime. This is known as a dynamic include (or runtime include) and uses the following syntax:

<jsp:include page="/jsp/userinfopage.jsp" flush="true" />

For those of you who are familiar with C syntax, a static include is comparable to a #include statement. A dynamic include is similar to a function call. They are both useful, but serve different purposes.

Note:

Both static includes and dynamic includes can be used only between pages in the same servlet context.

Logistics of Static Includes

A static include increases the size of the generated code for the including JSP page, as though the text of the included page is physically copied into the including page during translation (at the point of the include directive). If a page is included multiple times within an including page, multiple copies are made.

A JSP page that is statically included does not need to stand as an independent, translatable entity. It simply consists of text that will be copied into the including page. The including page, with the included text copied in, must then be translatable. And, in fact, the including page does not have to be translatable prior to having the included page copied into it. A sequence of statically included pages can each be fragments unable to stand on their own.

Logistics of Dynamic Includes

A dynamic include does not significantly increase the size of the generated code for the including page, although method calls, such as to the request dispatcher, will be added. The dynamic include results in runtime processing being switched from the including page to the included page, as opposed to the text of the included page being physically copied into the including page.

A dynamic include does increase processing overhead, with the necessity of the additional call to the request dispatcher.

A page that is dynamically included must be an independent entity, able to be translated and executed on its own. Likewise, the including page must be independent as well, able to be translated and executed without the dynamic include.

Advantages, Disadvantages, and Typical Uses

Static includes affect page size; dynamic includes affect processing overhead. Static includes avoid the overhead of the request dispatcher that a dynamic include necessitates, but may be problematic where large files are involved. (There is a 64K size limit on the service method of the generated page implementation class--see "Workarounds for Large Static Content in JSP Pages".)

Overuse of static includes can also make debugging your JSP pages difficult, making it harder to trace program execution. Avoid subtle interdependencies between your statically included pages.

Static includes are typically used to include small files whose content is used repeatedly in multiple JSP pages. For example:

Dynamic includes are useful for modular programming. You may have a page that sometimes executes on its own but sometimes is used to generate some of the output of other pages. Dynamically included pages can be reused in multiple including pages without increasing the size of the including pages.

When to Consider Creating and Using JSP Tag Libraries

Some situations dictate that the development team consider creating and using custom tags. In particular, consider the following situations:

Replacing Java Syntax

Because one cannot count on JSP developers being experienced in Java programming, they may not be ideal candidates for coding Java logic in the page--logic that dictates presentation and format of the JSP output, for example.

This is a situation where JSP tag libraries might be helpful. If many of your JSP pages will require such logic in generating their output, a tag library to replace Java logic would be a great convenience for JSP developers.

An example of this is the JML sample tag library provided with Oracle9i. This library, documented in the Oracle9iAS Containers for J2EE JSP Tag Libraries and Utilities Reference, includes tags that support logic equivalent to Java loops and conditionals.

Manipulating or Redirecting JSP Output

Another common situation for custom tags is if special runtime processing of the response output is required. Perhaps the desired functionality requires an extra processing step or redirection of the output to somewhere other than the browser.

An example is to create a custom tag that you can place around a body of text whose output will be redirected into a log file instead of to a browser, such as in the following example (where cust is the prefix for the tag library and log is one of the library's tags):

<cust:log>
   Today is <%= new java.util.Date() %>
   Text to log.
   More text to log.
   Still more text to log.
</cust:log>

See "Tag Handlers" for information about processing of tag bodies.

Use of a Central Checker Page

For general management or monitoring of your JSP application, it may be useful to use a central "checker" page that you include from each page in your application. A central checker page could accomplish tasks such as the following during execution of each page:

There could be many more uses as well.

As an example, consider a session checker class, MySessionChecker, that implements the HttpSessionBindingListener interface. (See "Standard Session Resource Management with HttpSessionBindingListener".)

public class MySessionChecker implements HttpSessionBindingListener
{
   ...
   
   valueBound(HttpSessionBindingEvent event)
   {...}
   
   valueUnbound(HttpSessionBindingEvent event)
   {...}
   
   ...
}

You can create a checker JSP page, suppose centralcheck.jsp, that includes something like the following:

<jsp:useBean id="sessioncheck" class="MySessionChecker" scope="session" />

In any page that includes centralcheck.jsp, the servlet container will call the valueUnbound() method implemented in the MySessionChecker class as soon as sessioncheck goes out of scope (at the end of the session). Presumably this is to manage session resources. You could include centralcheck.jsp at the end of each JSP page in your application.

Workarounds for Large Static Content in JSP Pages

JSP pages with large amounts of static content (essentially, large amounts of HTML code without content that changes at runtime) may result in slow translation and execution.

There are two primary workarounds for this (either workaround will speed translation):

Another possible, though unlikely, problem with JSP pages that have large static content is that most (if not all) JVMs impose a 64K byte size limit on the code within any single method. Although javac would be able to compile it, the JVM would be unable to execute it. Depending on the implementation of the JSP translator, this may become an issue for a JSP page, because generated Java code from essentially the entire JSP page source file goes into the service method of the page implementation class. (Java code is generated to output the static HTML to the browser, and Java code from any scriptlets is copied directly.)

Another possible, though rare, scenario is for the Java scriptlets in a JSP page to be large enough to create a size limit problem in the service method. If there is enough Java code in a page to create a problem, however, then the code should be moved into JavaBeans.

Method Variable Declarations Versus Member Variable Declarations

In "Scripting Elements", it is noted that JSP <%! ... %> declarations are used to declare member variables, while method variables must be declared in <% ... %> scriptlets.

Be careful to use the appropriate mechanism for each of your declarations, depending on how you want to use the variables:

Consider the following example, decltest.jsp:

<HTML>
<BODY>
<% double f2=0.0; %>
<%! double f1=0.0; %>
Variable declaration test.
</BODY>
</HTML>

This results in something like the following code in the page implementation class:

package ...;
import ...;

public class decltest extends oracle.jsp.runtime.HttpJsp {
   ...

   // ** Begin Declarations
   double f1=0.0;                  // *** f1 declaration is generated here ***
   // ** End Declarations

   public void _jspService
                (HttpServletRequest request, HttpServletResponse response) 
                throws IOException, ServletException {
      ...

      try {
         out.println( "<HTML>");
         out.println( "<BODY>");
         double f2=0.0;      // *** f2 declaration is generated here ***
         out.println( "");
         out.println( "");
         out.println( "Variable declaration test.");
         out.println( "</BODY>");
         out.println( "</HTML>");
         out.flush();
      }
      catch( Exception e) {
         try {
            if (out != null) out.clear();
         }
         catch( Exception clearException) {
         }
      finally {
         if (out != null) out.close();
      }
   }
}
Note:

This code is provided for conceptual purposes only. Most of the class is deleted for simplicity, and the actual code of a page implementation class generated by the Oracle JSP translator would differ somewhat.

Page Directive Characteristics

This section discusses the following page directive characteristics:

Page Directives Are Static

A page directive is static; it is interpreted during translation. You cannot specify dynamic settings to be interpreted at runtime. Consider the following examples:

Example 1

The following page directive is valid.

<%@ page contentType="text/html; charset=EUCJIS" %>
Example 2

The following page directive is not valid and will result in an error. (EUCJIS is hard-coded here, but the example also holds true for any character set determined dynamically at runtime.)

<% String s="EUCJIS"; %>
<%@ page contentType="text/html; charset=<%=s%>" %>

For some page directive settings there are workarounds. Reconsidering Example 2, there is a setContentType() method that allows dynamic setting of the content type, as described in "Dynamic Content Type Settings".

Page Directive Import Settings Are Cumulative

Java import settings in page directives within a JSP page are cumulative.

Within any single JSP page, the following two examples are equivalent:

<%@ page language="java" %>
<%@ page import="sqlj.runtime.ref.DefaultContext, java.sql.*" %>

or:

<%@ page language="java" %>
<%@ page import="sqlj.runtime.ref.DefaultContext" %>
<%@ page import="java.sql.*" %>

After the first page directive import setting, the import setting in the second page directive adds to the set of classes or packages to be imported, as opposed to replacing the classes or packages to be imported.

JSP Preservation of White Space and Use with Binary Data

The Oracle JSP container (and JavaServer Pages implementations in general) preserves source code white space, including carriage returns and linefeeds, in what is output to the browser. Insertion of such white space may not be what the developer intended, and typically makes JSP technology a poor choice for generating binary data.

White Space Examples

The following two JSP pages produce different HTML output, due to the use of carriage returns in the source code.

Example 1--No Carriage Returns

The following JSP page does not have carriage returns after the Date() and getParameter() calls. (The third and fourth lines, starting with the Date() call, actually comprise a single wraparound line of code.)

nowhitsp.jsp:

<HTML>
<BODY>
<%= new java.util.Date() %> <% String user=request.getParameter("user"); %> <%= 
(user==null) ? "" : user %>
<B>Enter name:</B>
<FORM METHOD=get>
<INPUT TYPE="text" NAME="user" SIZE=15>
<INPUT TYPE="submit" VALUE="Submit name">
</FORM>
</BODY>
</HTML>

This results in the following HTML output to the browser. (Note that there are no blank lines after the date.)

<HTML>
<BODY>
Tue May 30 20:07:04 PDT 2000  
<B>Enter name:</B>
<FORM METHOD=get>
<INPUT TYPE="text" NAME="user" SIZE=15>
<INPUT TYPE="submit" VALUE="Submit name">
</FORM>
</BODY>
</HTML>
Example 2--Carriage Returns

The following JSP page does include carriage returns after the Date() and getParameter() calls.

whitesp.jsp:

<HTML>
<BODY>
<%= new java.util.Date() %>
<% String user=request.getParameter("user"); %>
<%= (user==null) ? "" : user %>
<B>Enter name:</B>
<FORM METHOD=get>
<INPUT TYPE="text" NAME="user" SIZE=15>
<INPUT TYPE="submit" VALUE="Submit name">
</FORM>
</BODY>
</HTML>

This results in the following HTML output to the browser.

<HTML>
<BODY>
Tue May 30 20:19:20 PDT 2000


<B>Enter name:</B>
<FORM METHOD=get>
<INPUT TYPE="text" NAME="user" SIZE=15>
<INPUT TYPE="submit" VALUE="Submit name">
</FORM>
</BODY>
</HTML>

Note the two blank lines between the date and the "Enter name:" line. In this particular case the difference is not significant, because both examples produce the same appearance in the browser, as shown below. However, this discussion nevertheless demonstrates the general point about preservation of white space.

Text description of whitesp.gif follows.

Text description of the illustration whitesp.gif

Reasons to Avoid Binary Data in JSP Pages

For the following reasons, JSP pages are a poor choice for generating binary data. Generally you should use servlets instead.

Trying to generate binary data in JSP pages largely misses the point of JSP technology anyway, which is intended to simplify the programming of dynamic textual content.

Oracle XML Support

This section describes the following Oracle support features for XML that may be useful in JSP pages:

For information about additional support for XML and XSL, refer to the Oracle9iAS Containers for J2EE JSP Tag Libraries and Utilities Reference.

XML-Alternative Syntax

JSP tags, such as <%...%> for scriptlets, <%!...%> for declarations, and <%=...%> for expressions, are not syntactically valid within an XML document. Sun Microsystems addressed this in the JavaServer Pages Specification, Version 1.1 by defining equivalent JSP tags using syntax that is XML-compatible. This is implemented through a standard DTD that you can specify within a jsp:root start tag at the beginning of an XML document.

This functionality allows you, for example, to write XML-based JSP pages in an XML authoring tool.

The Oracle JSP container does not use this DTD directly or require you to use a jsp:root tag, but the Oracle JSP translator includes logic to recognize the alternative syntax specified in the standard DTD. Table 4-1 documents this syntax.

Table 4-1 XML-Alternative Syntax  
Standard JSP Syntax XML-Alternative JSP Syntax

<%@ directive ...%>

Such as:
<%@ page ... %>
<%@ include ... %>

<jsp:directive.directive ... />

Such as:
<jsp:directive.page ... />
<jsp:directive.include ... />

<%! ... %> (declaration)

<jsp:declaration>
...declarations go here...
</jsp:declaration>

<%= ... %> (expression)

<jsp:expression>
...expression goes here...
</jsp:expression>

<% ... %> (scriptlet)

<jsp:scriptlet>
...code fragment goes here...
</jsp:scriptlet>

JSP action tags, such as jsp:useBean, for the most part already use syntax that complies with XML. Changes due to quoting conventions or for request-time attribute expressions may be necessary, however.

OracleXMLQuery Class

The oracle.xml.sql.query.OracleXMLQuery class is provided with Oracle9i as part of the XML-SQL utility for XML functionality in database queries. This class requires file xsu12.jar (for JDK 1.2.x) or xsu111.jar (for JDK 1.1.x), both of which are provided with Oracle9i.

For information about the OracleXMLQuery class and other XML-SQL utility features, refer to the Oracle9i XML Developer's Kits Guide - XDK.

Key JSP Configuration Issues

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

Optimization of JSP Execution

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

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 globalization support 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

When the Oracle JSP container 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 setting the JSP developer_mode flag to false. The default setting is true. For information about how to set this flag in the JServ environment, see "Setting JSP Parameters in JServ".

Note:

This discussion is not relevant for pre-translation scenarios.

Not Using an HTTP Session

If a JSP page does not require an HTTP session (essentially, does not require storage or retrieval of 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.

Classpath and Class Loader Issues

The Oracle JSP container 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 JSP classpath combines the following elements:

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

Oracle JSP 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. The Oracle JSP container 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 WEB-INF directories are not relevant in a servlet 2.0 environment, such as JServ.)

Important:

If you want classes in the WEB-INF directories to be loaded by the system class loader instead of the Oracle JSP 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 _pages directory is the default location for translated and compiled JSP pages (as output by the JSP translator).

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. The Oracle JSP container 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:

Oracle JSP classpath Configuration Parameter

Use the JSP classpath configuration parameter to add to the Oracle JSP classpath.

For more information about this parameter, see "Oracle JSP Configuration Parameters". For information about how to set this parameter in the JServ environment, see "Setting JSP Parameters in JServ".

Advantages and Disadvantages of the Oracle JSP Class Loader

Using the Oracle JSP class loader results in the following advantages and disadvantages:

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

Oracle JSP Runtime Page and Class Reloading

This section describes conditions under which the Oracle JSP container retranslates pages, reloads pages, and reloads classes during runtime.

Dynamic Page Retranslation

As a Web application is running, the Oracle JSP container by default will automatically retranslate and reload a JSP page whenever the page source is modified.

The JSP container checks whether the last-modified time of the page implementation class file, as indicated in the Oracle JSP in-memory cache, is older than the last-modified time of the JSP page source file.

You can avoid the overhead of the Oracle JSP container checking timestamps for retranslation by setting the JSP developer_mode flag to false. This is advantageous in a deployment environment, where source and class files will typically not change. For more information about this flag, see "Oracle JSP Configuration Parameters". For how to set it in a JServ environment, see "Setting JSP Parameters in JServ".

Notes:
  • Because of the usage of in-memory values for the class file last-modified time, note that removing a page implementation class file from the file system will not cause the Oracle JSP container to retranslate the associated JSP page source. The JSP container will only retranslate when the JSP page source file timestamp changes.
  • The class file will be regenerated when the cache is lost. This happens whenever a request is directed to this page after the server is restarted or after another page in this application has been retranslated.

Dynamic Page Reloading

The Oracle JSP container will automatically reload a JSP page (in other words, reload the generated page implementation class) in the following circumstances:

Dynamic Class Reloading

By default, before the Oracle JSP container dispatches a request that will execute a Java class that was loaded by the Oracle JSP class loader, it checks to see if the class file has been modified since it was first loaded. If the class has been modified, then the Oracle JSP class loader reloads it.

This applies only to classes in the Oracle JSP classpath, which includes the following:

As mentioned in the preceding section, "Dynamic Page Reloading", reloading a class results in the dynamic reloading of JSP pages that reference that class.

Important:
  • Remember that classes must be in the JSP classpath, not the system classpath, to be dynamically reloaded. If they are in the system classpath as well, the system class loader may take precedence in some circumstances, possibly interfering with JSP automatic-reloading functionality.
  • Dynamic class reloading can be expensive in terms of CPU usage. You can disable this feature by setting the JSP developer_mode parameter to false. This is appropriate in deployment environments where classes are not expected to change.

For information about the classpath and developer_mode configuration parameters and how to set them in a JServ environment, see "Oracle JSP Configuration Parameters" and "Setting JSP Parameters in JServ".

Go to previous page Go to next page
Oracle
Copyright © 2000, 2002 Oracle Corporation.
All Rights Reserved.
Go To Documentation Library
Home		 Go To Product List
Book List		 Go To Table Of Contents
Contents		 Go To Index
Index
Master Index
Feedback