Release 2 (9.2)
Part Number A96657-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle9i Support for JavaServer Pages Reference Release 2 (9.2) Part Number A96657-01 |
|
Oracle JSP 1.1.x.x releases are complete implementations of the Sun Microsystems JavaServer Pages Specification, Version 1.1.
This chapter provides an overview of the Oracle JSP implementation, including programmatic extensions, and support in both Oracle and non-Oracle environments.
The following topics are covered here:
This section introduces the Oracle JSP container and servlet environment supplied with Oracle9i release 2, and also discusses the role of the Oracle HTTP Server and mod_jserv component in running database-access Web applications.
Version 1.1.2.4 of the Oracle JSP container is supplied with Oracle9i release 2. This version is fully compliant with the Sun Microsystems JavaServer Pages Specification, Version 1.1.
The supplied servlet environment with Oracle9i release 2 is Apache JServ, a servlet 2.0 environment. The JSP 1.1 specification calls for a servlet 2.1(b) or later environment, but you can use the Oracle JSP version 1.1.2.4 container with any servlet 2.0 or later environment--extensions have been built in to the JSP container to emulate some servlet 2.2 functionality. This is further discussed in "Portability and Functionality Across Servlet Environments".
Special considerations in using the Oracle JSP container with a servlet 2.0 environment are discussed in Chapter 9, "Oracle JSP in Apache JServ". This chapter also documents JSP and JServ configuration.
Instead of using JServ, you can acquire any of several other servlet environments. Options include the following, in particular:
OC4J is supplied with the Oracle9i Application Server and is also available in a standalone version from the Oracle Technology Network (http://otn.oracle.com).
Tomcat, from the Apache Software Foundation, includes a servlet 2.2 environment. It also includes a JSP 1.1 reference implementation, but you can use the Oracle JSP container on top of it.
Because you can use a servlet 2.2 environment with the Oracle JSP container, and because the JSP container itself emulates some servlet 2.2 functionality, many servlet 2.2 features are discussed in this document, even though the environment supplied with Oracle9i release 2 is servlet 2.0.
OC4J documentation is available with Oracle9i Application Server releases and from the Oracle Technology Network.
For configuration information for Tomcat, as well as for the Sun Microsystems JavaServer Web Developer's Kit (JSWDK), refer to Appendix A, "Getting Started in Alternative Environments".
Oracle HTTP Server, powered by the Apache Web server, is included with the 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, dynamic content is delivered through various Apache mod components provided either by Apache or by other vendors such as Oracle. (Static content is usually 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.
To access Oracle9i data from JSP pages or servlets running in the JServ servlet environment that is provided with Oracle9i, use mod_jserv. This mod was developed by Apache and is provided with Oracle9i.
The mod_jserv component delegates HTTP requests to JSP pages or servlets running in the JServ servlet container in a middle-tier JVM. Oracle9i release 2 supplies the JServ servlet container, which supports the servlet 2.0 specification. 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 JServ Servlet Environments".
Refer to Apache documentation for mod_jserv configuration information. (This documentation is provided with Oracle9i.)
The Oracle 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.
The Oracle JSP container 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. The Oracle JSP container provides functionality equivalent to what is lacking in older servlet environments.
Furthermore, the Oracle JSP 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 JSP pages 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 particular 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.
The Oracle JSP 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 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 "Oracle JSP Application and Session Support for JServ".)
Because of this extended functionality, the Oracle JSP container is not limited by the underlying servlet environment.
Some visual Java programming tools now support JSP coding. In particular, Oracle9i JDeveloper supports the Oracle JSP container and includes the following features:
See "Deployment of JSP Pages with Oracle9i 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, or to the following Web site:
http://otn.oracle.com/products/jdev/content.html
You should be able to install and run the Oracle JSP container on any server environment supporting servlet specification 2.0 or higher. In particular, it has been tested in the following environments as of release 1.1.2.4:
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 the Oracle JSP container 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 the Oracle JSP container 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 provides an overview of the following Oracle-specific programming extensions supported by the Oracle JSP container:
JspScopeListener for event handlingglobals.jsa file for application support in servlet 2.0 environmentsThe Oracle JSP container also provides the following extended functionality, documented in the Oracle9iAS Containers for J2EE JSP Tag Libraries and Utilities Reference, through custom tag libraries and custom JavaBeans that are generally portable to other JSP environments:
All these features are introduced in the following subsections.
The Oracle JSP extensions listed in this section, documented later in this manual, 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. The Oracle JSP container and its translator support SQLJ programming in JSP scriptlets.
SQLJ statements are indicated by the #sql token. You can trigger the Oracle JSP translator to invoke the Oracle SQLJ translator by using the file name extension .sqljsp for the JSP source code file.
For more information, see "Oracle JSP Support for Oracle SQLJ".
Oracle9i release 2 provides extended globalization support for servlet environments that cannot encode multibyte request parameters and bean property settings.
For such environments, the Oracle JSP container supports the translate_params configuration parameter, which can be enabled to direct the JSP container to override the servlet container and do the encoding itself.
For more information, see "Oracle JSP Extended Support for Multibyte Parameter Encoding".
Oracle9i release 2 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 "Oracle JSP Event Handling with JspScopeListener".
For servlet 2.0 environments, where servlet contexts are not fully defined, the Oracle JSP container 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 Oracle JSP 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.
For more information, see "Oracle JSP Application and Session Support for JServ".
The Oracle extensions discussed in this section are implemented through standard tag libraries or custom JavaBeans and are generally portable to other JSP environments.
These features are documented in the Oracle9iAS Containers for J2EE JSP Tag Libraries and Utilities Reference.
JSP pages generally rely on core Java types in representing scalar values. However, 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, Oracle9i release 2 provides the JmlBoolean, JmlNumber, JmlFPNumber, and JmlString JavaBean classes in package oracle.jsp.jml to wrap the most common Java types.
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.
Oracle9i release 2 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.
In addition, the Oracle JSP translator supports XML-alternative syntax as specified in the Sun Microsystems JavaServer Pages Specification, Version 1.1. For information, see "XML-Alternative Syntax".
Oracle9i release 2 supplies a set of custom JavaBeans for use in database access. The following beans are provided in the oracle.jsp.dbutil package:
ConnBean--Open a simple database connection.ConnCacheBean--Use the Oracle connection caching implementation for database connections.DBBean--Execute a database query.CursorBean--Provide general DML support for queries and for UPDATE, INSERT, and DELETE statements.Oracle9i release 2 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.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.
Oracle9i release 2 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>
As mentioned earlier, you can use the Oracle JSP framework in a variety of server environments. The Oracle JSP container offers two distinct execution models:
ojspc command-line tool is available to translate the pages. Then, when the end-user requests the JSP page, it is executed directly, with no translation necessary.JSP pages usually run in an on-demand translation model. This includes typical usage with the JServ servlet environment.
When a JSP page is requested from a Web server that incorporates the Oracle JSP 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 Oracle JSP 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 JServ are discussed in detail in "Mapping JSP File Name Extensions for JServ".
Developers may want to pre-translate their JSP pages before deploying them, for reasons such as the following:
For more information, see "General Use of ojspc for Pre-Translation" and "Deployment of Binary Files Only".
Oracle9i release 2 supplies the ojspc command-line utility for pre-translating JSP pages. This utility has options that allow you to set an appropriate base directory for the output files, depending on how you want to deploy the application. The ojspc utility is documented in "Details of the ojspc Pre-Translation Tool".
|
 Copyright © 2000, 2002 Oracle Corporation. All Rights Reserved. |
|