Oracle9iAS Containers for J2EE Support for JavaServer Pages Reference Release 2 (9.0.2) Part Number A95882-01 |
|
This chapter reviews standard features and functionality of JavaServer Pages technology, then concludes with a discussion of JSP execution models. For further general information, consult the Sun Microsystems JavaServer Pages Specification, Version 1.1.
For an overview of the JSP implementation in OC4J, see Chapter 2, "Overview of the Oracle JSP Implementation". Also note that Appendix A, "Servlet and JSP Technical Background", provides related background on standard servlet and JSP technology.
The following topics are covered here:
JavaServer Pages(TM) is a technology specified by Sun Microsystems as a convenient way of generating dynamic content in pages that are output by a Web application (an application running on a Web server).
This technology, which is closely coupled with Java servlet technology, allows you to include Java code snippets and calls to external Java components within the HTML code (or other markup code, such as XML) of your Web pages. JavaServer Pages (JSP) technology works nicely as a front-end for business logic and dynamic functionality in JavaBeans and Enterprise JavaBeans (EJBs).
JSP code is distinct from other Web scripting code, such as JavaScript, in a Web page. Anything that you can include in a normal HTML page can be included in a JSP page as well.
In a typical scenario for a database application, a JSP page will call a component such as a JavaBean or Enterprise JavaBean, and the bean will directly or indirectly access the database, generally through JDBC or perhaps SQLJ.
A JSP page is translated into a Java servlet before being executed, and processes HTTP requests and generates responses similarly to any other servlet. JSP technology offers a more convenient way to code the servlet. The translation typically occurs on demand, but sometimes in advance.
Furthermore, JSP pages are fully interoperable with servlets--JSP pages can include output from a servlet or forward to a servlet, and servlets can include output from a JSP page or forward to a JSP page.
Here is an example of a simple JSP page. For an explanation of JSP syntax elements used here, see "Overview of JSP Syntax Elements".
<HTML> <HEAD><TITLE>The Welcome User JSP</TITLE></HEAD> <BODY> <% String user=request.getParameter("user"); %> <H3>Welcome <%= (user==null) ? "" : user %>!</H3> <P><B> Today is <%= new java.util.Date() %>. Have a nice day! :-)</B></P> <B>Enter name:</B> <FORM METHOD=get> <INPUT TYPE="text" NAME="user" SIZE=15> <INPUT TYPE="submit" VALUE="Submit name"> </FORM> </BODY> </HTML>
In a JSP page, Java elements are set off by tags such as <%
and %>
, as in the preceding example. In this example, Java snippets get the user name from an HTTP request object, print the user name, and get the current date.
This JSP page will produce the following output if the user inputs the name "Amy":
Combining Java code and Java calls into an HTML page is more convenient than using straight Java code in a servlet. JSP syntax gives you a shortcut for coding dynamic Web pages, typically requiring much less code than Java servlet syntax. Following is an example contrasting servlet code and JSP code.
import javax.servlet.*; import javax.servlet.http.*; import java.io.*; public class Hello extends HttpServlet { public void doGet(HttpServletRequest rq, HttpServletResponse rsp) { rsp.setContentType("text/html"); try { PrintWriter out = rsp.getWriter(); out.println("<HTML>"); out.println("<HEAD><TITLE>Welcome</TITLE></HEAD>"); out.println("<BODY>"); out.println("<H3>Welcome!</H3>"); out.println("<P>Today is "+new java.util.Date()+".</P>"); out.println("</BODY>"); out.println("</HTML>"); } catch (IOException ioe) { // (error processing) } } }
See "The Servlet Interface" for some background information about the standard HttpServlet
abstract class, HttpServletRequest
interface, and HttpServletResponse
interface.
<HTML> <HEAD><TITLE>Welcome</TITLE></HEAD> <BODY> <H3>Welcome!</H3> <P>Today is <%= new java.util.Date() %>.</P> </BODY> </HTML>
Note how much simpler JSP syntax is. Among other things, it saves Java overhead such as package imports and try...catch
blocks.
Additionally, the JSP translator automatically handles a significant amount of servlet coding overhead for you in the .java
file that it outputs, such as directly or indirectly implementing the standard javax.servlet.jsp.HttpJspPage
interface (see "Standard JSP Interfaces and Methods") and adding code to acquire an HTTP session.
Also note that because the HTML of a JSP page is not embedded within Java print statements, as it is in servlet code, you can use HTML authoring tools to create JSP pages.
JSP technology allows separating the development efforts between the HTML code that determines static page presentation, and the Java code that processes business logic and presents dynamic content. It therefore becomes much easier to split maintenance responsibilities between presentation and layout specialists who may be proficient in HTML but not Java, and code specialists who may be proficient in Java but not HTML.
In a typical JSP page, most Java code and business logic will not be within snippets embedded in the JSP page--instead, it will be in JavaBeans or Enterprise JavaBeans that are invoked from the JSP page.
JSP technology offers the following syntax for defining and creating an instance of a JavaBeans class:
<jsp:useBean id="pageBean" class="mybeans.NameBean" scope="page" />
This example creates an instance, pageBean
, of the mybeans.NameBean
class. The scope
parameter will be explained later in this chapter.
Later in the page, you can use this bean instance, as in the following example:
Hello <%= pageBean.getNewName() %> !
This prints "Hello Julie !", for example, if the name "Julie" is in the newName
attribute of pageBean
, which might occur through user input.
The separation of business logic from page presentation allows convenient division of responsibilities between the Java expert who is responsible for the business logic and dynamic content--this developer owns and maintains the code for the NameBean
class--and the HTML expert who is responsible for the static presentation and layout of the Web page that the application user sees--this developer owns and maintains the code in the .jsp
file for this JSP page.
Tags used with JavaBeans--useBean
to declare the JavaBean instance and getProperty
and setProperty
to access bean properties--are further discussed in "JSP Actions and the <jsp: > Tag Set".
JavaServer Pages technology is typically used for dynamic HTML output, but the Sun Microsystems JavaServer Pages Specification, Version 1.1 also supports additional types of structured, text-based document output. A JSP translator does not process text outside of JSP elements, so any text that is appropriate for Web pages in general is typically appropriate for a JSP page as well.
A JSP page takes information from an HTTP request and accesses information from a data server (such as through a SQL database query). It combines and processes this information and incorporates it, as appropriate, into an HTTP response with dynamic content. The content can be formatted as HTML, DHTML, XHTML, or XML, for example.
For information about XML support, refer to "XML-Alternative Syntax" and to the Oracle9iAS Containers for J2EE JSP Tag Libraries and Utilities Reference.
You have seen a simple example of JSP syntax in "What a JSP Page Looks Like". Now here is a top-level list of syntax categories and topics:
This section introduces each category, including basic syntax and a few examples. For more information, see the Sun Microsystems JavaServer Pages Specification, Version 1.1.
Notes: There are XML-compatible alternatives to the syntax for JSP directives, declarations, expressions, and scriptlets. See "XML-Alternative Syntax". |
Directives provide instruction to the JSP container regarding the entire JSP page. This information is used in translating or executing the page. The basic syntax is as follows:
<%@ directive attribute1="value1" attribute2="value2"... %>
The JSP 1.1 specification supports the following directives:
page
--Use this directive to specify any of a number of page-dependent attributes, such as the scripting language to use, a class to extend, a package to import, an error page to use, or the JSP page output buffer size. For example:
<%@ page language="java" import="packages.mypackage" errorPage="boof.jsp" %>
or, to set the JSP page output buffer size to 20 KB (the default is 8 KB):
<%@ page buffer="20kb" %>
or, to unbuffer the page:
<%@ page buffer="none" %>
include
--Use this directive to specify a resource that contains text or code to be inserted into the JSP page when it is translated.
Example:
<%@ include file="/jsp/userinfopage.jsp" %>
Specify either a page-relative or context-relative path to the resource. (See "Requesting a JSP Page" for discussion of page-relative and context-relative paths.)
Notes:
|
taglib
--Use this directive to specify a library of custom JSP tags that will be used in the JSP page. Vendors can extend JSP functionality with their own sets of tags. This directive indicates the location of a tag library description file and a prefix to distinguish use of tags from that library. For example:
<%@ taglib uri="/oracustomtags" prefix="oracust" %>
Later in the page, use the oracust
prefix whenever you want to use one of the tags in the library (presume this library includes a tag dbaseAccess
):
<oracust:dbaseAccess ... > ... </oracust:dbaseAccess>
JSP tag libraries and tag library description files are introduced later in this chapter, in "Tag Libraries", and discussed in detail in Chapter 7, "JSP Tag Libraries".
JSP scripting elements include the following categories of snippets of Java code that can appear in a JSP page:
A JSP declaration uses standard Java syntax within the <%!...%>
declaration tags to declare a member variable or method. This will result in a corresponding declaration in the generated servlet code. For example:
<%! double f1=0.0; %>
This example declares a member variable, f1
. In the servlet class code generated by the JSP translator, f1
will be declared at the class top level.
A JSP expression does not end in a semicolon, and is contained within <%=...%>
tags. For example:
<P><B> Today is <%= new java.util.Date() %>. Have a nice day! </B></P>
A scriptlet, or code fragment, can consist of anything from a partial line to multiple lines of Java code. You can use them within the HTML code of a JSP page to set up conditional branches or a loop, for example.
A JSP scriptlet is contained within <%...%>
scriptlet tags, using normal Java syntax.
Example 1:
<% if (pageBean.getNewName().equals("")) { %> I don't know you. <% } else { %> Hello <%= pageBean.getNewName() %>. <% } %>
Three one-line JSP scriptlets are intermixed with two lines of HTML code (one of which includes a JSP expression, which does not require a semicolon). Note that JSP syntax allows HTML code to be the code that is conditionally executed within the if
and else
branches (inside the Java brackets set out in the scriptlets).
The preceding example assumes the use of a JavaBean instance, pageBean
.
Example 2:
<% if (pageBean.getNewName().equals("")) { %> I don't know you. <% empmgr.unknownemployee(); } else { %> Hello <%= pageBean.getNewName() %>. <% empmgr.knownemployee(); } %>
This example adds more Java code to the scriptlets. It assumes the use of a JavaBean instance, pageBean
, and assumes that some object, empmgr
, was previously instantiated and has methods to execute appropriate functionality for a known employee or an unknown employee.
Note: Use a JSP scriptlet to declare method variables, as opposed to member variables, as in the following example: <% double f2=0.0; %>
This scriptlet declares a method variable, Member variables are declared in JSP declarations as described above. For a comparative discussion, see "Method Variable Declarations Versus Member Variable Declarations". |
Comments are contained within <%--...--%>
tags. Unlike HTML comments, these comments are not visible when a user views the page source.
Example:
<%-- Execute the following branch if no user name is entered. --%>
In this document, the term JSP object refers to a Java class instance declared within or accessible to a JSP page. JSP objects can be either:
scope
setting you choose.
or:
scope
setting of the particular object type.
This section covers the following topics:
Explicit objects are typically JavaBean instances that are declared and created in jsp:useBean
action statements. The jsp:useBean
statement and other action statements are described in "JSP Actions and the <jsp: > Tag Set", but here is an example:
<jsp:useBean id="pageBean" class="mybeans.NameBean" scope="page" />
This statement defines an instance, pageBean
, of the NameBean
class that is in the mybeans
package. The scope
parameter is discussed in "Object Scopes".
You can also create objects within Java scriptlets or declarations, just as you would create Java class instances in any Java program.
JSP technology makes available to any JSP page a set of implicit objects. These are Java class instances that are created automatically by the JSP container and that allow interaction with the underlying servlet environment.
The following implicit objects are available. For information about methods available with these objects, refer to the Sun Microsystems Javadoc for the noted classes and interfaces at the following locations (for servlet 2.2 and servlet 2.3 classes, respectively):
http://java.sun.com/products/servlet/2.2/javadoc/index.html http://java.sun.com/products/servlet/2.3/javadoc/index.html
page
This is an instance of the JSP page implementation class that was created when the page was translated, and that implements the interface javax.servlet.jsp.HttpJspPage
; page
is synonymous with this
within a JSP page.
request
This represents an HTTP request and is an instance of a class that implements the javax.servlet.http.HttpServletRequest
interface, which extends the javax.servlet.ServletRequest
interface.
response
This represents an HTTP response and is an instance of a class that implements the javax.servlet.http.HttpServletResponse
interface, which extends the javax.servlet.ServletResponse
interface.
The response
and request
objects for a particular request are associated with each other.
pageContext
This represents the page context of a JSP page, which is provided for storage and access of all page
scope objects of a JSP page instance. A pageContext
object is an instance of the javax.servlet.jsp.PageContext
class.
The pageContext
object has page
scope, making it accessible only to the JSP page instance with which it is associated.
session
This represents an HTTP session and is an instance of a class that implements the javax.servlet.http.HttpSession
class.
application
This represents the servlet context for the Web application and is an instance of the javax.servlet.ServletContext
class.
The application
object is accessible from any JSP page instance running as part of any instance of the application within a single JVM. (The programmer should be aware of the server architecture regarding use of JVMs.)
out
This is an object that is used to write content to the output stream of a JSP page instance. It is an instance of the javax.servlet.jsp.JspWriter
class, which extends the java.io.Writer
class.
The out
object is associated with the response
object for a particular request.
config
This represents the servlet configuration for a JSP page and is an instance of a class that implements the javax.servlet.ServletConfig
interface. Generally speaking, servlet containers use ServletConfig
instances to provide information to servlets during initialization. Part of this information is the appropriate ServletContext
instance.
exception
(JSP error pages only)
This implicit object applies only to JSP error pages--these are pages to which processing is forwarded when an exception is thrown from another JSP page. They must have the page
directive isErrorPage
attribute set to true
.
The implicit exception
object is a java.lang.Exception
instance that represents the uncaught exception that was thrown from another JSP page and that resulted in the current error page being invoked.
The exception
object is accessible only from the JSP error page instance to which processing was forwarded when the exception was encountered.
For an example of JSP error processing and use of the exception
object, see "JSP Runtime Error Processing".
Any of the implicit objects discussed in the preceding section may be useful. The following example uses the request
object to retrieve and display the value of the username
parameter from the HTTP request:
<H3> Welcome <%= request.getParameter("username") %> ! <H3>
The request
object, like the other implicit objects, is available automatically; it is not explicitly instantiated.
Objects in a JSP page, whether explicit or implicit, are accessible within a particular scope. In the case of explicit objects, such as a JavaBean instance created in a jsp:useBean
action, you can explicitly set the scope with the following syntax, as in the example in "Explicit Objects":
scope="scopevalue"
There are four possible scopes:
scope="page"
(default scope)--The object is accessible only from within the JSP page where it was created. A page-scope object is stored in the implicit pageContext
object. The page
scope ends when the page stops executing.
Note that when the user refreshes the page while executing a JSP page, new instances will be created of all page-scope objects.
scope="request"
--The object is accessible from any JSP page servicing the same HTTP request that is serviced by the JSP page that created the object. A request-scope object is stored in the implicit request
object. The request
scope ends at the conclusion of the HTTP request.
scope="session"
--The object is accessible from any JSP page that is sharing the same HTTP session as the JSP page that created the object. A session-scope object is stored in the implicit session
object. The session
scope ends when the HTTP session times out or is invalidated.
scope="application"
--The object is accessible from any JSP page that is used in the same Web application as the JSP page that created the object, within any single Java virtual machine. The concept is similar to that of a Java static variable. An application-scope object is stored in the implicit application
servlet context object. The application
scope ends when the application itself terminates, or when the JSP container or servlet container shuts down.
You can think of these four scopes as being in the following progression, from narrowest scope to broadest scope:
page
< request
< session
< application
If you want to share an object between different pages in an application, such as when forwarding execution from one page to another, or including content from one page in another, you cannot use page
scope for the shared object; in this case, there would be a separate object instance associated with each page. The narrowest scope you can use to share an object between pages is request
. (For information about including and forwarding pages, see "JSP Actions and the <jsp: > Tag Set" below.)
JSP action elements result in some sort of action occurring while the JSP page is being executed, such as instantiating a Java object and making it available to the page. Such actions may include the following:
Action elements use a set of standard JSP tags that use <jsp:
tag
... >
syntax. Although directives and scripting elements described earlier in this chapter are sufficient to code a JSP page, the <jsp:>
tags described here provide additional functionality and convenience.
Here is the general JSP tag syntax:
<jsp:tag attr1="value1" attr2="value2" ... attrN="valueN"> ...body... </jsp:tag>
or, where there is no body:
<jsp:tag attr1="value1", ..., attrN="valueN" />
The JSP specification includes the following standard action tags, which are introduced and briefly discussed here:
jsp:useBean
The jsp:useBean
tag creates an instance of a specified JavaBean class, gives the instance a specified name, and defines the scope within which it is accessible (such as from anywhere within the current JSP page instance).
Example:
<jsp:useBean id="pageBean" class="mybeans.NameBean" scope="page" />
This example creates a page-scoped instance pageBean
of the mybeans.NameBean
class. This instance is accessible only from the JSP page instance that creates it.
jsp:setProperty
The jsp:setProperty
tag sets one or more bean properties. The bean must have been previously specified in a jsp:useBean
tag. You can directly specify a value for a specified property, or take the value for a specified property from an associated HTTP request parameter, or iterate through a series of properties and values from the HTTP request parameters.
The following example sets the user
property of the pageBean
instance (defined in the preceding jsp:useBean
example) to a value of "Smith":
<jsp:setProperty name="pageBean" property="user" value="Smith" />
The following example sets the user
property of the pageBean
instance according to the value set for a parameter called username
in the HTTP request:
<jsp:setProperty name="pageBean" property="user" param="username" />
Or, if the bean property and request parameter have the same name (user
), you can simply set the property as follows:
<jsp:setProperty name="pageBean" property="user" />
The following example results in iteration over the HTTP request parameters, matching bean property names with request parameter names and setting bean property values according to the corresponding request parameter values:
<jsp:setProperty name="pageBean" property="*" />
jsp:getProperty
The jsp:getProperty
tag reads a bean property value, converts it to a Java string, and places the string value into the implicit out
object so that it can be displayed as output. The bean must have been previously specified in a jsp:useBean
tag. For the string conversion, primitive types are converted directly, and object types are converted using the toString()
method specified in the java.lang.Object
class.
The following example puts the value of the user
property of the pageBean
bean into the out
object:
<jsp:getProperty name="pageBean" property="user" />
jsp:param
You can use jsp:param
tags in conjunction with jsp:include
, jsp:forward
, and jsp:plugin
tags (described below).
Used with jsp:forward
and jsp:include
tags, a jsp:param
tag optionally provides key/value pairs for parameter values in the HTTP request
object. New parameters and values specified with this action are added to the request
object, with new values taking precedence over old.
The following example sets the request
object parameter username
to a value of Smith
:
<jsp:param name="username" value="Smith" />
jsp:include
The jsp:include
tag inserts additional static or dynamic resources into the page at request-time as the page is displayed. Specify the resource with a relative URL (either page-relative or application-relative).
The flush
attribute is mandatory. The Sun Microsystems JavaServer Pages Specification, Version 1.1, supports only a "true" setting, which results in the buffer being flushed to the browser when a jsp:include
action is executed. The JSP 1.2 specification and OC4J JSP in Oracle9iAS 9.0.2, however, support a "false" setting.
You can also have an action body with jsp:param
tags, as shown in the second example.
Examples:
<jsp:include page="/templates/userinfopage.jsp" flush="true" />
or:
<jsp:include page="/templates/userinfopage.jsp" flush="true" > <jsp:param name="username" value="Smith" /> <jsp:param name="userempno" value="9876" /> </jsp:include>
Note that the following syntax would work as an alternative to the preceding example:
<jsp:include page="/templates/userinfopage.jsp?username=Smith&userempno=9876" flush="true" />
Notes:
|
jsp:forward
The jsp:forward
tag effectively terminates execution of the current page, discards its output, and dispatches a new page--either an HTML page, a JSP page, or a servlet.
The JSP page must be buffered to use a jsp:forward
tag; you cannot set buffer="none"
in a page
directive. The action will clear the buffer, not outputting contents to the browser.
As with jsp:include
, you can also have an action body with jsp:param
tags, as shown in the second of the following examples.
Examples:
<jsp:forward page="/templates/userinfopage.jsp" />
or:
<jsp:forward page="/templates/userinfopage.jsp" > <jsp:param name="username" value="Smith" /> <jsp:param name="userempno" value="9876" /> </jsp:forward>
jsp:plugin
The jsp:plugin
tag results in the execution of a specified applet or JavaBean in the client browser, preceded by a download of Java plugin software if necessary.
Specify configuration information, such as the applet to run and the code base, using jsp:plugin
attributes. The JSP container might provide a default URL for the download, but you can also specify attribute nspluginurl="
url
"
(for a Netscape browser) or iepluginurl="
url
"
(for an Internet Explorer browser).
Use nested jsp:param
tags within <jsp:params>
and </jsp:params>
start and end tags to specify parameters to the applet or JavaBean. (Note that these jsp:params
start and end tags are not necessary when using jsp:param
in a jsp:include
or jsp:forward
action.)
Use <jsp:fallback>
and </jsp:fallback>
start and end tags to delimit alternative text to execute if the plugin cannot run.
The following example, from the Sun Microsystems JavaServer Pages Specification, Version 1.1, shows the use of an applet plugin:
<jsp:plugin type=applet code="Molecule.class" codebase="/html" > <jsp:params> <jsp:param name="molecule" value="molecules/benzene.mol" /> </jsp:params> <jsp:fallback> <p> Unable to start the plugin. </p> </jsp:fallback> </jsp:plugin>
Many additional parameters--such as ARCHIVE
, HEIGHT
, NAME
, TITLE
, and WIDTH
--are allowed in the jsp:plugin
tag as well. Use of these parameters is according to the general HTML specification.
In addition to the standard JSP tags discussed above, the JSP specification lets vendors define their own tag libraries and also lets vendors implement a framework allowing customers to define their own tag libraries.
A tag library defines a collection of custom tags and can be thought of as a JSP sub-language. Developers can use tag libraries directly when manually coding a JSP page, but they might also be used automatically by Java development tools. A tag library must be portable between different JSP container implementations.
Import a tag library into a JSP page using the taglib
directive introduced in "Directives".
Key concepts of standard JavaServer Pages support for JSP tag libraries include the following topics:
A tag handler implements the action of a custom tag. A tag handler is an instance of a Java class that implements either the Tag
or BodyTag
interface (depending on whether the tag uses a body between a start tag and an end tag) in the standard javax.servlet.jsp.tagext
package.
Custom tag actions can create server-side objects available for use by the tag itself or by other scripting elements such as scriptlets. This is accomplished by creating or updating scripting variables.
Details regarding scripting variables that a custom tag defines must be specified in a subclass of the standard javax.servlet.jsp.tagext.TagExtraInfo
abstract class. This document refers to such a subclass as a tag-extra-info class. The JSP container uses instances of these classes during translation.
A tag library description (TLD) file is an XML document that contains information about a tag library and about individual tags of the library. The file name of a TLD has the .tld
extension.
A JSP container uses the TLD file in determining what action to take when it encounters a tag from the library.
web.xml
for tag libraries
The Sun Microsystems Java Servlet Specification, Version 2.2 (and higher) describes a standard deployment descriptor for servlets--the web.xml
file. JSP applications can use this file in specifying the location of a JSP tag library description file.
For JSP tag libraries, the web.xml
file can include a taglib
element and two subelements: taglib-uri
and taglib-location
.
For information about these topics, see "Standard Tag Library Framework". For further information, see the Sun Microsystems JavaServer Pages Specification, Version 1.1.
For complete information about the tag libraries provided with OC4J, see the Oracle9iAS Containers for J2EE JSP Tag Libraries and Utilities Reference.
This section provides a top-level look at how a JSP page is run, including on-demand translation (the first time a JSP page is run), the role of the JSP container and the servlet container, and error processing.
A JSP container is an entity that translates, executes, and processes JSP pages and delivers requests to them.
The exact make-up of a JSP container varies from implementation to implementation, but it will consist of a servlet or collection of servlets. The JSP container, therefore, is executed by a servlet container. Servlet containers are summarized in "Servlet Containers".
A JSP container can be incorporated into a Web server if the Web server is written in Java, or the container can be otherwise associated with and used by the Web server.
There are two distinct execution models for JSP pages:
It is typical to run JSP pages in an on-demand translation scenario. When a JSP page is requested from a Web server that incorporates the JSP container, a front-end servlet is instantiated and invoked, assuming proper Web server configuration. This servlet can be thought of as the front-end of the JSP container. In OC4J, it is oracle.jsp.runtimev2.JspServlet
.
JspServlet
locates the JSP page, translates and compiles it if necessary (if the translated 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
. This is handled automatically during OC4J installation, as discussed in "JSP Container Setup".
As an alternative to the typical on-demand scenario, developers may want to pre-translate their JSP pages before deploying them. This can offer the following advantages, for example:
For more information, see "JSP Pre-Translation" and "Deployment of Binary Files Only".
Oracle 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 "The ojspc Pre-Translation Utility".
Presuming the typical on-demand translation scenario, a JSP page is usually executed through the following steps:
.jsp
file name.
.jsp
file name extension in the URL, the servlet container of the Web server invokes the JSP container.
.java
file and then compiling the .java
file to produce a servlet .class
file.
The servlet class generated by the JSP translator extends a class (provided by the JSP container) that implements the javax.servlet.jsp.HttpJspPage
interface (described in "Standard JSP Interfaces and Methods"). The servlet class is referred to as the page implementation class. This document will refer to instances of page implementation classes as JSP page instances.
Translating a JSP page into a servlet automatically incorporates standard servlet programming overhead into the generated servlet code, such as implementing the HttpJspPage
interface and generating code for its service method.
The JSP page instance will then process the HTTP request, generate an HTTP response, and pass the response back to the client.
A JSP page can be requested either directly--through a URL--or indirectly--through another Web page or servlet.
As with a servlet or HTML page, the end-user can request a JSP page directly by URL. For example, suppose you have a HelloWorld
JSP page that is located under a myapp
directory, as follows, where myapp
is mapped to the myapproot
root context in the Web server:
myapp/dir1/HelloWorld.jsp
You can request it with a URL such as the following:
http://host:port/myapproot/dir1/HelloWorld.jsp
The first time the end-user requests HelloWorld.jsp
, the JSP container triggers both translation and execution of the page. With subsequent requests, the JSP container triggers page execution only; the translation step is no longer necessary.
Note:
This is just a general example. By default in OC4J in Oracle9iAS 9.0.2, the context path must start with "/j2ee" if you want processing to be routed to OC4J through the Oracle HTTP Server and |
JSP pages, like servlets, can also be executed indirectly--linked from a regular HTML page or referenced from another JSP page or from a servlet.
When invoking one JSP page from a JSP statement in another JSP page, the path can be either relative to the application root--known as context-relative or application-relative--or relative to the invoking page--known as page-relative. An application-relative path starts with "/"; a page-relative path does not.
Be aware that, typically, neither of these paths is the same path as used in a URL or HTML link. Continuing the example in the preceding section, the path in an HTML link is the same as in the direct URL request, as follows:
<a href="/myapp/dir1/HelloWorld.jsp" /a>
The application-relative path in a JSP statement is:
<jsp:include page="/dir1/HelloWorld.jsp" flush="true" />
The page-relative path to invoke HelloWorld.jsp
from a JSP page in the same directory is:
<jsp:forward page="HelloWorld.jsp" />
("JSP Actions and the <jsp: > Tag Set" discusses the jsp:include
and jsp:forward
statements.)
|
Copyright © 2000, 2002 Oracle Corporation. All Rights Reserved. |
|