Release 1.1.2.3
Part Number A90208-01
 Home |
 Book List |
 Contents |
 Index |  Master Index |  Feedback |
| OracleJSP Support for JavaServer Pages Developer's Guide and Reference Release 1.1.2.3 Part Number A90208-01 |
|
OracleJSP release 1.1.2.x is a complete implementation of the Sun Microsystems JavaServer Pages Specification, Version 1.1.
This chapter introduces features of OracleJSP as well as discussing support for OracleJSP in various environments, particularly the Oracle9i Servlet Engine (OSE). OSE is the Oracle9i servlet container.
For an overview of standard JavaServer Pages features, see Chapter 1, "General Overview".
The following topics are covered here:
Oracle's JavaServer Pages implementation is highly portable across server platforms and servlet environments. It also supplies a framework for Web applications in older servlet environments, where servlet context behavior was not yet sufficiently defined.
OracleJSP can run on any servlet environment that complies with version 2.0 or higher of the Sun Microsystems Java Servlet Specification. This is in contrast to most JSP implementations, which require a servlet 2.1(b) or higher implementation. As the next section explains, OracleJSP provides functionality equivalent to what is lacking in older servlet environments.
Furthermore, the OracleJSP container is independent of the server environment and its servlet implementation. This is in contrast to vendors who deliver their JSP implementation as part of their servlet implementation instead of as a standalone product.
This portability makes it much easier to run OracleJSP in both your development environment and the target environment, as opposed to having to use a different JSP implementation on your development system because of any server or servlet platform limitations. There are usually benefits to developing on a system with the same JSP container as the target server; but realistically speaking, there is usually some variation between environments.
Because of interdependence between servlet specifications and JSP functionality, Sun Microsystems has tied versions of the JavaServer Pages Specification to versions of the Java Servlet Specification. According to Sun, JSP 1.0 requires a servlet 2.1(b) implementation, and JSP 1.1 requires a servlet 2.2 implementation.
The servlet 2.0 specification was limited in that it provided only a single servlet context per Java virtual machine, instead of a servlet context for each application. The servlet 2.1 specification allowed, but did not mandate, a separate servlet context for each application. The servlet 2.1(b) and servlet 2.2 specifications mandated separate servlet contexts. (For background information about servlets and servlet contexts, see "Background on Servlets".)
The OracleJSP container, however, offers functionality that emulates the application support provided with the servlet 2.1(b) specification. This allows a full application framework in a servlet 2.0 environment such as Apache/JServ. This includes providing applications with distinct ServletContext and HttpSession objects.
This extended support is provided through a file, globals.jsa, that acts as a JSP application marker, application and session event handler, and centralized location for application-global declarations and directives. (For information, see "Overview of globals.jsa Functionality".)
Because of this extended functionality, OracleJSP is not limited by the underlying servlet environment.
This section provides brief overviews of Oracle environments that support and provide OracleJSP, covering the following topics:
The Oracle9i Servlet Engine, the servlet container in Oracle9i, supports a JSP pre-translation model. JSP pages are translated into servlets prior to or during deployment to Oracle9i.
For the other Oracle environments, the OracleJSP container supports the typical on-demand translation model, typically translating the pages at runtime. OracleJSP is designed to run effectively in either situation and provide consistent semantics regardless of your choice of server.
If your JSP pages are intended to access an Oracle9i database, you have the option of executing them in the Oracle9i Servlet Engine (OSE), either inside the Oracle9i database or inside the Oracle9i Application Server middle-tier database cache. OSE, which is included with Oracle9i, incorporates the OracleJSP container. This reduces communication overhead compared to JSP execution in a middle tier. Access to the database is through the Oracle JDBC server-side internal driver.
The OSE execution model requires the developer to take some special steps to deploy the JSP pages to Oracle9i. This includes pre-translating the pages, loading them into Oracle9i, and "publishing" them to make them available for execution.
During installation of Oracle9i, the Oracle HTTP Server powered by Apache is set as the default Web server, acting as a front-end for JSP and servlet applications running in OSE. Refer to your installation instructions if you want to change this setting.
In Oracle9i database release 9.0.1, the Oracle9i Servlet Engine supports the servlet 2.2 and JSP 1.1 specifications, incorporating OracleJSP release 1.1.2.3.
The Oracle9i Application Server is a scalable, secure, middle-tier application server. It can be used to deliver Web content, host Web applications, connect to back-office applications, and make these services accessible to any client browser. Users can access information, perform business analysis, and run business applications on the Internet or corporate intranets or extranets.
To deliver this range of content and services, Oracle9i Application Server release 1.0.x incorporates the Oracle HTTP Server (powered by Apache), a middle-tier database cache for read-only data, Oracle Forms Services and Oracle Reports Services to support Oracle Forms-based applications and reports generation, and various business logic runtime environments that support Enterprise JavaBeans, stored procedures, and Oracle Business Components for Java.
For database access, the Oracle HTTP Server can route HTTP requests to servlets or JSP pages running in either of the following scenarios:
mod_jserv module)
In this scenario, database access is through client-side/middle-tier JDBC drivers (using either JDBC or SQLJ code).
mod_ose module)
In this scenario, database access is through the JDBC server-side internal driver (using either JDBC or SQLJ code).
The Oracle9i Application Server 1.0.x releases include the Apache/JServ servlet environment, supporting the servlet 2.0 specification, and provide JSP environments as follows:
See the Oracle9i Application Server Documentation Library for more information about the Oracle9i Application Server.
Oracle HTTP Server, powered by the Apache Web server, is included with the Oracle9i Application Server and Oracle9i database as the HTTP entry point for Web applications accessing the database. Database access is through Apache add-on modules.
The remainder of this section covers the following topics:
In using the Oracle HTTP Server, powered by Apache, dynamic content is delivered through various Apache mod components provided either by Apache or by other vendors such as Oracle. (Static content is typically delivered from the file system.) An Apache mod is typically a module of C code, running in the Apache address space, that passes requests to a particular mod-specific processor. (The mod software will have been written specifically for use with the particular processor.)
The following Apache mods are of interest to OracleJSP developers:
mod_ose is provided by Oracle for JSP pages and servlets that have been deployed to Oracle9i and will be executed by the Oracle9i Servlet Engine inside the database or middle-tier database cache address space.
mod_jserv is provided by Apache and can be used in accessing Oracle9i data from JSP pages or servlets running in the Apache/JServ servlet environment in a middle-tier JVM.
The mod_ose component, supplied by Oracle, delegates HTTP requests to JSP pages or servlets running in OSE inside the database or middle-tier database cache. It communicates with OSE using HTTP over the Oracle Net protocol and can handle either stateless or stateful requests. Each virtual domain configured in the Oracle HTTP Server is associated with a database connection string (an Oracle Net name-value list) that indicates where to make a connection to execute the request. The connection uses Oracle Net directly, providing the same load balancing and hot backup functionality as OCI.
If an application running in an Oracle9i Application Server framework uses mod_ose, then the application server's Apache/JServ servlet 2.0 environment is not involved. The Oracle9i Servlet Engine's own servlet 2.2 environment is used instead.
JSP applications and servlets running in OSE in the database or middle-tier database cache use the Oracle JDBC server-side internal driver for rapid database access. For an overview of OSE, see "Overview of the Oracle9i Servlet Engine (OSE)".
You can use the Oracle9i session shell exportwebdomain command to configure mod_ose to find published servlets and JSP pages in the database.
See the Oracle9i Servlet Engine Developer's Guide for more information about mod_ose and for information about the exportwebdomain command.
The mod_jserv component, supplied by Apache, delegates HTTP requests to JSP pages or servlets running in the Apache/JServ servlet container in a middle-tier JVM. Oracle9i Application Server release 1.0.x includes the Apache/JServ servlet container, which supports the servlet 2.0 specification, and either JDK 1.1.8 or 1.2.2. The middle-tier environment may or may not be on the same physical host as the back-end Oracle9i database.
Communication between mod_jserv and middle-tier JVMs uses a proprietary Apache/JServ protocol over TCP/IP. The mod_jserv component can delegate requests to multiple JVMs in a pool for load balancing.
JSP applications running in middle-tier JVMs use the Oracle JDBC OCI driver or Thin driver to access the database.
Servlet 2.0 environments (as opposed to servlet 2.1 or 2.2 environments) have issues that require special consideration. See "Considerations for Apache/JServ Servlet Environments".
Refer to Apache documentation for mod_jserv configuration information. (This documentation is provided with Oracle9i.)
Developers who are targeting the Oracle9i database or middle-tier database cache from JSP applications have the following options:
mod_jserv.
mod_ose.
When you use the Oracle HTTP Server, be aware that the Apache/JServ servlet container has a different default doc root for static files than the Oracle9i Servlet Engine has. See "Doc Root for Oracle9i Application Server Versus Oracle9i Servlet Engine".
Note:
Running in Apache/JServ, because it uses a standard JVM (currently JDK 1.2.2 or 1.1.8), is necessary if you want to use the JDBC OCI driver or if the application requires Java features not available in the Oracle JVM (JNI, for example).
However, running in Apache/JServ has the disadvantage of requiring a pool of multiple JVMs that must be configured manually. (For more information, refer to the Apache mod_jserv documentation provided with Oracle9i.)
In using the Oracle9i Servlet Engine, access through the Oracle HTTP Server and mod_ose is the typical scenario and is recommended, although employing OSE directly as the Web server (either in the database or database cache) is feasible.
In particular, Oracle HTTP Server and mod_ose can handle the following situations that OSE by itself cannot:
This is typically not possible when using OSE as a Web server directly. In a UNIX environment, for example, port 80 is accessible only from the root account, and end-users do not have root access.
The default installation of Oracle9i uses the Oracle HTTP Server as the front-end Web server for JSP pages and servlets that run in OSE.
In addition to the Oracle9i Servlet Engine and Oracle9i Application Server, the following Oracle environments support OracleJSP:
Oracle Application Server (OAS) preceded the Oracle Internet Application Server, which is now known as the Oracle9i Application Server. OAS is a scalable, standards-based middle-tier environment for application logic, offering database integration in supporting business applications in both corporate and e-business environments.
New customers will presumably use the Oracle9i Application Server, discussed previously, instead of OAS. For existing OAS customers, however, Oracle Application Server release 4.0.8.2 includes a servlet 2.1 environment and OracleJSP release 1.0.0.6.0 (supporting the JSP 1.0 specification).
Refer to the Oracle Application Server Developer's Guide: JServlet and JSP Applications for more information.
Oracle Web-to-go, a component of Oracle9i Lite, consists of a collection of modules and services that facilitate development, deployment, and management of mobile Web applications.
Web-to-go lets developers extend Web-based applications to intermittently connected users without coding the infrastructure required for replication, synchronization, and other networking issues. Unlike traditional mobile computing technologies, which rely on custom or proprietary application-programming interfaces (APIs), Web-to-go uses industry-standard Internet technologies.
Web-to-go release 1.3 provides a servlet 2.1 environment and OracleJSP release 1.0.0.6.1 (supporting the JSP 1.0 specification). Future releases will offer a servlet 2.2 environment and OracleJSP 1.1.x.
Refer to the Oracle Web-to-go Implementation Guide for more information.
JDeveloper is a Java development tool, rather than a "platform" like the other Oracle products listed here. It incorporates a Web listener, servlet runner, and the OracleJSP container for execution and testing.
See "Oracle JDeveloper Support for OracleJSP" for more information.
JDeveloper version 3.1 provides a servlet 2.1 environment and OracleJSP release 1.0.0.6.1 (supporting the JSP 1.0 specification). Future releases will offer a servlet 2.2 environment and OracleJSP 1.1.x.
You should be able to install and run the OracleJSP container on any server environment supporting servlet specification 2.0 or higher. In particular, OracleJSP has been tested in the following environments as of release 1.1.2.x:
This is a Web server and servlet 2.0 environment without a JSP environment. To run JSP pages, you must install a JSP environment on top of it.
This is a Web server with the servlet 2.1 and JavaServer Pages 1.0 reference implementations. You can, however, install OracleJSP on top of the JSWDK servlet environment to replace the original JSP environment.
This cooperative effort between Sun Microsystems and the Apache Software Foundation is a Web server with the servlet 2.2 and JavaServer Pages 1.1 reference implementations. You can, however, install OracleJSP on top of the Tomcat servlet environment to replace the original JSP environment. You can also run Tomcat in conjunction with the Apache Web server instead of using the Tomcat Web server.
This section is an overview of extended programming features supported by OracleJSP.
OracleJSP provides the following extended functionality through custom tag libraries and custom JavaBeans, all of which are portable to other JSP environments:
OracleJSP also provides the following Oracle-specific extensions:
JspScopeListener for event handling
globals.jsa file for application support
Discussion of these topics is followed by a brief description of how OracleJSP pages can interact with Oracle PL/SQL Server Pages.
The Oracle extensions discussed in this section are implemented either through the OracleJSP JML sample tag library or through custom JavaBeans. They are portable to other JSP environments.
JSP pages generally rely on core Java datatypes in representing scalar values, but neither of the following type categories is fully suitable for use in JSP pages:
int, float, and double
Values of these types cannot have a specified scope--they cannot be stored in a JSP scope object (for page, request, session, or application scope), because only objects can be stored in a scope object.
java.lang package, such as Integer, Float, and Double
Values of these types are objects, so they can theoretically be stored in a JSP scope object. However, they cannot be declared in a jsp:useBean action, because the wrapper classes do not follow the JavaBean model and do not provide a zero-argument constructor.
Additionally, instances of the wrapper classes are immutable. To change a value, you must create a new instance and assign it appropriately.
To work around these limitations, OracleJSP provides the JmlBoolean, JmlNumber, JmlFPNumber, and JmlString JavaBean classes in package oracle.jsp.jml to wrap the most common Java datatypes.
See "JML Extended Datatypes" for more information.
You can use JSP syntax to generate any text-based MIME type, not just HTML code. In particular, you can dynamically create XML output. When you use JSP pages to generate an XML document, however, you often want a stylesheet applied to the XML data before it is sent to the client. This is difficult in JavaServer Pages technology, because the standard output stream used for a JSP page is written directly back through the server.
OracleJSP provides special tags in its sample JML tag library to specify that all or part of a JSP page should be transformed through an XSL stylesheet before it is output. You can use this JML tag multiple times in a single JSP page if you want to specify different style sheets for different portions of the page. Note that the JML tag library is portable to other JSP environments.
In addition, the OracleJSP translator supports XML-alternative syntax as specified in the Sun Microsystems JavaServer Pages Specification, Version 1.1.
See "OracleJSP Support for XML and XSL" for more information.
OracleJSP supplies a set of custom JavaBeans for use in accessing the Oracle9i database or middle-tier database cache. The following beans are provided in the oracle.jsp.dbutil package:
ConnBean opens a simple database connection.
ConnCacheBean uses Oracle's connection caching implementation for database connections.
DBBean executes a database query.
CursorBean provides general DML support for UPDATE, INSERT, and DELETE statements, as well as queries.
See "Oracle Data-Access JavaBeans" for more information.
OracleJSP provides a custom tag library for SQL functionality. The following tags are provided:
dbOpen--Open a database connection.
dbClose--Close a database connection.
dbQuery--Execute a query.
dbCloseQuery--Close the cursor for a query.
dbNextRow--Move to the next row of the result set.
dbExecute--Execute any SQL DML or DDL statement.
See "OracleJSP Tag Library for SQL" for more information.
Although the Sun Microsystems JavaServer Pages Specification, Version 1.1 supports scripting languages other than Java, Java is the primary language used. Even though JavaServer Pages technology is designed to separate the dynamic/Java development effort from the static/HTML development effort, it is no doubt still a hindrance if the Web developer does not know any Java, especially in small development groups where no Java experts are available.
OracleJSP provides custom tags as an alternative--the JSP Markup Language (JML). The Oracle JML sample tag library provides an additional set of JSP tags so that you can script your JSP pages without using Java statements. JML provides tags for variable declarations, control flow, conditional branches, iterative loops, parameter settings, and calls to objects. The JML tag library also supports XML functionality, as noted previously.
The following example shows use of the jml:for tag, repeatedly printing "Hello World" in progressively smaller headings (H1, H2, H3, H4, H5):
<jml:for id="i" from="<%= 1 %>" to="<%= 5 %>" > <H<%=i%>> Hello World! </H<<%=i%>> </jml:for>
For more information, see "Overview of the JSP Markup Language (JML) Sample Tag Library".
|
Note: OracleJSP versions preceding the JSP 1.1 specification used an Oracle-specific compile-time implementation of the JML tag library. This implementation is still supported as an alternative to the standard runtime implementation. For information, see Appendix C, "Compile-Time JML Tag Support". |
The OracleJSP extensions listed in this section are not portable to other JSP environments.
Dynamic server pages commonly include data extracted from databases; however, JavaServer Pages technology does not offer built-in support to facilitate database access. JSP developers typically must rely on the standard Java Database Connectivity (JDBC) API or a custom set of database JavaBeans.
SQLJ is a standard syntax for embedding static SQL instructions directly in Java code, greatly simplifying database-access programming. OracleJSP and the OracleJSP translator support SQLJ programming in JSP scriptlets.
SQLJ statements are indicated by the #sql token. You can trigger the OracleJSP translator to invoke the Oracle SQLJ translator by using the file name extension .sqljsp for the JSP source code file.
For more information, see "OracleJSP Support for Oracle SQLJ".
OracleJSP provides extended globalization support for servlet environments that cannot encode multibyte request parameters and bean property settings.
For such environments, OracleJSP offers the translate_params configuration parameter, which can be enabled to direct OracleJSP to override the servlet container and do the encoding itself.
For more information, see "OracleJSP Extended Support for Multibyte Parameter Encoding".
OracleJSP provides the JspScopeListener interface for lifecycle management of Java objects of various scopes within a JSP application.
Standard servlet and JSP event-handling is provided through the javax.servlet.http.HttpSessionBindingListener interface, but this handles session-based events only. The Oracle JspScopeListener can handle page-based, request-based, and application-based events as well.
For more information, see "OracleJSP Event Handling--JspScopeListener".
For servlet 2.0 environments, where servlet contexts are not fully defined, OracleJSP defines a file, globals.jsa, to extend servlet application support.
Within any single Java virtual machine, there can be a globals.jsa file for each application (or, equivalently, for each servlet context). This file supports the concept of Web applications through use as an application location marker. Based on globals.jsa functionality, the OracleJSP container can also mimic servlet context and HTTP session behavior for servlet environments, where such behavior is not sufficiently defined.
The globals.jsa file also provides a vehicle for global Java declarations and JSP directives across all JSP pages of an application.
Oracle provides a product called PL/SQL Server Pages (PSP). PSP technology allows embedded PL/SQL scriptlets and stored procedure calls within an HTML page, offering development advantages similar to those offered by JSP technology; namely, that coding the dynamic portion of the page and the static portion of the page can be largely separate development efforts. An HTML expert can code the static part of the page and a PL/SQL expert can code the dynamic part of the page. The syntax used to distinguish PL/SQL scriptlets in a PSP page is identical to that used to distinguish Java scriptlets in a JSP page.
The remainder of this section discusses support for JSP-PSP interaction, and includes some background on PSP URLs.
For general information about PL/SQL Server Pages, see the Oracle9i Application Developer's Guide - Fundamentals.
When an end-user runs a PSP application, PSP pages are translated into stored procedures for execution by the embedded PL/SQL gateway in producing output to the Web browser. The embedded PL/SQL gateway in Oracle9i executes in a servlet wrapper, and JSP pages running in the Oracle9i Servlet Engine can interact with PSP pages as follows (as of Oracle9i release 9.0.1):
jsp:forward).
jsp:include).
include directive to include a file during translation).
For information about the embedded PL/SQL gateway, refer to the Oracle9i Servlet Engine Developer's Guide and to Using the PL/SQL Gateway in the Oracle Application Server 9i Documentation Library.
Each PSP page, when loaded and compiled in the database, becomes a PL/SQL stored procedure. The name of the stored procedure for a PSP page is either explicitly declared in the page, using <%@ plsql procedure="proc-name" %> syntax, or is derived from the name of the PSP file.
Given the name of the PL/SQL stored procedure, the URL is determined according to the following general syntax:
http://host[:port]/some-prefix/dad/[schema.]proc-name
In this syntax, <some-prefix> is plsql for the embedded PL/SQL module, and <dad> is the database access descriptor to run the stored procedure.
For more information, see the Oracle9i Application Developer's Guide - Fundamentals.
OracleJSP release 1.1.2.3, a complete implementation the JSP 1.1 specification, is provided with Oracle9i database release 9.0.1.
Some other Oracle platforms supporting OracleJSP have not yet incorporated the latest OracleJSP release, however--they integrate OracleJSP release 1.1.0.0.0 (also a JSP 1.1 implementation) or 1.0.0.6.1 or 1.0.0.6.0 (JSP 1.0 implementations).
Table 2-1 summarizes which OracleJSP releases are provided with which Oracle platform releases as of this writing.
The "OracleJSP Feature Notes" column refers to OracleJSP release 1.1.2.x features documented in this manual that are limited in the OracleJSP release noted for the particular Oracle platform, or have special significance for the platform. For more information, see "OracleJSP Feature Notes for Previous Releases".
It is possible to download, incorporate, and use more recent OracleJSP versions with the above Oracle platforms; the OracleJSP versions documented are the versions that are supplied as part of the product.
To verify the OracleJSP release being used in a particular environment, retrieve the release number from the implicit application object in a JSP page, as follows:
<%= application.getAttribute("oracle.jsp.versionNumber") %>
The following points describe the significance of the "OracleJSP Feature Notes" column in Table 2-1 above, regarding previous OracleJSP releases.
globals.jsa mechanism to support a more complete application framework. See "OracleJSP Application and Session Support for Servlet 2.0" for more information.
Use of JML in OracleJSP release 1.0.0.6.x requires a taglib directive (as specified for JSP 1.1 and supported by OracleJSP 1.1.x.x), but the directive must specify the class that contains the library, as follows:
<%@ taglib uri="oracle.jsp.parse.OpenJspRegisterLib" prefix="jml" %>
By contrast, when using a JSP implementation that complies with the JSP 1.1 specification, such as OracleJSP 1.1.2.x or 1.1.0.0.0, the taglib directive specifies the tag library description file (in a .tld file or .jar file), as follows:
<%@ taglib uri="/WEB-INF/tlds/jmltags.tld" prefix="jml" %>
For information about the JML compile-time implementation, see Appendix C, "Compile-Time JML Tag Support".
As mentioned earlier, you can use the OracleJSP framework in a variety of server environments. OracleJSP offers two distinct execution models:
OracleJSP uses the typical on-demand translation model for all server environments that support OracleJSP, other than the Oracle9i Servlet Engine. This includes using OracleJSP with the Apache Web server with JServ, for example, as well as various Oracle environments.
When a JSP page is requested from a Web server that incorporates the OracleJSP container, the servlet oracle.jsp.JspServlet is instantiated and invoked (assuming proper Web server configuration). This servlet can be thought of as the front-end of the OracleJSP container.
JspServlet locates the JSP page, translates and compiles it if necessary (if the page implementation class does not exist or has an earlier timestamp than the JSP page source), and triggers its execution.
Note that the Web server must be properly configured to map the *.jsp file name extension (in a URL) to JspServlet. The steps to accomplish this for Apache/JServ, the Sun Microsystems JWSDK, and Tomcat are discussed in detail in "Configuration of Web Server and Servlet Environment to Run OracleJSP".
JSP pages intended to run in the Oracle9i Servlet Engine (OSE) are pre-translated and deployed to Oracle9i as working servlets. OSE incorporates the OracleJSP runtime.
Perform the following steps to deploy JSP pages into Oracle9i:
Command-line tools are available to translate, load, and publish the pages. The translator creates the page implementation class in a .java file and compiles it into a .class file.
Hotloading can be enabled and accomplished through additional steps. This is a feature that allows more efficient use of literal strings such as the generated HTML tags in a page implementation class. See "Overview of Hotloaded Classes in Oracle9i".
Deployment to Oracle9i can be performed with the translation being done either beforehand on the client or as part of the deployment. For more information about these scenarios and the steps involved, see "Deployment to Oracle9i with Server-Side Translation" and "Deployment to Oracle9i with Client-Side Translation".
The Oracle9i Servlet Engine incorporates its own OracleJSP container, which consists of most of the overall OracleJSP container without the OracleJSP translator (because any JSP page that runs in the OSE environment is pre-translated).
The OSE includes front-end JSP processing, with functionality similar to JspServlet in the on-demand translation model.
The front-end component finds and executes JSP pages according to a servlet path (often referred to as a "virtual path") entered in the Oracle9i JNDI name space during publishing. You specify a servlet path name when you publish the JSP page.
Visual Java programming tools are beginning to support JSP coding. In particular, Oracle JDeveloper supports OracleJSP and includes the following features:
See "Deployment of JSP Pages with JDeveloper" for more information about JSP deployment support.
For debugging, JDeveloper can set breakpoints within JSP page source and can follow calls from JSP pages into JavaBeans. This is much more convenient than manual debugging techniques, such as adding print statements within the JSP page to output state into the response stream (for viewing in your browser) or to the server log (through the log() method of the implicit application object).
For information about JDeveloper, refer to their online help.
|
 Copyright © 1996-2001, Oracle Corporation. All Rights Reserved. |
|