Release 2 (9.0.2)
Part Number A95882-01
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle9iAS Containers for J2EE Support for JavaServer Pages Reference Release 2 (9.0.2) Part Number A95882-01 |
|
This chapter discusses important programming and runtime considerations in developing and executing JSP applications. The following topics are covered:
This section discusses issues you should consider when programming JSP pages, regardless of the particular target environment. The following assortment of topics are covered:
In addition to being aware of what is discussed in this section, you should be aware of JSP translation and deployment issues and behavior. See Chapter 6, "JSP Translation and Deployment".
Note:
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, 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.
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 tag, 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 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.
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 be fragments unable to stand on their own.
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.
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. (The service method of the generated page implementation class has a 64 KB size limit--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.
|
Note: OC4J offers "global includes" as a convenient way to statically include a file into multiple pages. See "Oracle JSP Global Includes". |
Some situations dictate that the development team consider creating and using custom tags. In particular, consider the following situations:
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 tag library provided with OC4J. 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.
Instead of having Web application programmers rely on Java APIs from servlets or JSP scriptlets to use product functionality or extensions, you can provide a tag library. A tag library can make the programmer's task much more convenient.
For example, tags as well as JavaBeans are provided with OC4J for sendmail and file access functionality. There is also a tag library as well as a Java API provided with the OC4J Web Object Cache. Similarly, while Oracle9iAS Personalization provides a Java API, OC4J also provides a tag library that you can use instead if you want to program a personalization application.
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 tags of the library):
<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.
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--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.
|
Note: OC4J offers "global includes" as a convenient way to statically include a file into multiple pages. See "Oracle JSP Global Includes". |
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):
jsp:include) to include its output in the JSP page output at runtime. See "JSP Actions and the <jsp: > Tag Set" for information about the jsp:include tag.
The JSP translator will do this for you if you enable the external_resource configuration parameter. This parameter is documented in "Configuration Parameter Descriptions".
For pre-translation, the -extres option of the ojspc tool also offer this functionality.
Another possible, though unlikely, problem with JSP pages that have large static content is that most (if not all) JVMs impose a 64 KB 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.
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:
<%! ... %> JSP declaration syntax is declared at the class level in the page implementation class that is generated by the JSP translator. In this case, if declaring an object instance, the object can be accessed simultaneously from multiple requests. Therefore, the object must be thread-safe, unless isThreadSafe="false" is declared in a page directive.
<% ... %> JSP scriptlet syntax is local to the service method of the page implementation class. Each time the method is called, a separate instance of the variable or object is created, so there is no need for thread safety.
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(); } } }
This section discusses the following page directive characteristics:
page directive is static and takes effect during translation--you cannot specify parameter settings to be evaluated at runtime.
import settings in page directives are cumulative within a JSP page.
A page directive is static; it is interpreted during translation. You cannot specify dynamic settings to be interpreted at runtime. Consider the following examples:
The following page directive is valid.
<%@ page contentType="text/html; charset=EUCJIS" %>
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 the second example, there is a setContentType() method that allows dynamic setting of the content type, as described in "Dynamic Content Type Settings".
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 containers generally preserve 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.
The following two JSP pages produce different HTML output, due to the use of carriage returns in the source code.
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 form 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 code 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>
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 code 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.
For the following reasons, JSP pages are a poor choice for generating binary data. Generally, you should use servlets instead.
JspWriter object.
.gif file, for example) or other uses where whitespace is significant.
Consider the following example:
<% out.getOutputStream().write(...binary data...) %> <% out.getOutputStream().write(...more binary data...) %>
In this case, the browser will receive an unwanted newline characters in the middle of the binary data or at the end, depending on the buffering of your output buffer. You can avoid this problem by not using a carriage return between the lines of code, but this is an undesirable programming style.
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.
This section discusses OC4J JSP features to consider when accessing data, covering the following topics:
For information about additional OC4J JSP data-access features--portable JavaBeans and tags for SQL functionality--see the Oracle9iAS Containers for J2EE JSP Tag Libraries and Utilities Reference.
Note:
You can use the following performance enhancement features, supported through Oracle JDBC extensions, in JSP applications in OC4J:
Most of these performance features are supported by the 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.
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 OC4J. Alternatively, you can use standard data source connection pooling functionality, which is supported by the ConnBean data-access JavaBean. These beans are 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 tags or directly through the class setter methods.
Refer to the OC4J demos for examples of using OracleConnectionCacheImpl directly. For information about the Oracle JDBC connection caching scheme and the OracleConnectionCacheImpl class, see the Oracle9i JDBC Developer's Guide and Reference.
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 OC4J. Each of these beans has a stmtCacheSize property that can be set through a jsp:setProperty tag or the bean setStmtCacheSize() method. 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.
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.
OC4J 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 tag 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.
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.
OC4J 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 tag 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.
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.
JSP pages can call EJBs to perform additional processing or data access. A typical application design uses JavaServer Pages as a front-end for the initial processing of client requests, with Enterprise JavaBeans being called to perform the work that involves reading from and writing to data sources. This section provides an overview of EJB usage, covering the following topics:
See the OC4J demos for a complete example incorporating JSP pages and EJBs.
The configuration and deployment steps for calling EJBs from JSP pages are similar to the steps for calling EJBs from servlets, which are described in the Oracle9iAS Containers for J2EE Servlet Developer's Guide. These steps include the following:
<ejb-ref> element in the application web.xml file for each EJB called from a JSP page.
ejb-jar.xml deployment descriptor that contains an <enterprise-beans> element with appropriate subelements, such as <session> or <entity>, that specify the types of EJBs. Within these subelements, specify the name, class name, and other details for each called EJB.
ejb-jar.xml file in the EJB archive. Deployment requirements are very similar to the requirements for servlets.
As with a servlet, the key steps required for a JSP page to invoke an EJB are the following:
page directive for this.)
Because you can use almost any servlet code in a JSP page in the form of a scriptlet, one straightforward way to call EJBs from a JSP page is to use the same code in a scriptlet that you would use in a servlet. This is one way to accomplish steps 2, 3, and 4.
Alternatively, you can use tags from the EJB tag library provided with OC4J. These tags simplify the coding. Essentially, they allow you to treat Enterprise JavaBeans similarly to regular JavaBeans, which are commonly used in JSP pages.
Refer to "Code Steps and Approaches for EJB Calls" above. As in that section, import the appropriate package in a page directive. Then use the OC4J EJB tags as follows. (See Chapter 7, "JSP Tag Libraries", for general information about JSP tag libraries.)
taglib directive to specify the tag prefix you will use and the location of the tag library description (TLD) file.
useHome tag.
createBean tag inside an EJB useBean tag.
iterate convenience tag allows you to apply business methods to each member of a collection of EJB objects, usually returned by a find method.
For more information about the EJB tag library, including detailed tag syntax, see the Oracle9iAS Containers for J2EE JSP Tag Libraries and Utilities Reference.
Deployment requirements are the same for the tag library approach as for the scriptlet code approach. As with any tag library, the TLD file and the library support files (tag handler classes and tag-extra-info classes) must be made accessible to your application.
SQLJ is a standard syntax for embedding static SQL instructions directly in Java code, greatly simplifying database-access programming. The OC4J JSP container supports Oracle SQLJ, allowing you to use SQLJ syntax in JSP statements. SQLJ statements are indicated by the #sql token.
For general information about Oracle SQLJ programming features, syntax, and command-line options, see the Oracle9i SQLJ Developer's Guide and Reference.
Following is a sample SQLJ JSP page. (The page directive imports classes that are typically required by SQLJ.)
<%@ page language="sqlj" import="sqlj.runtime.ref.DefaultContext,oracle.sqlj.runtime.Oracle" %> <HTML> <HEAD> <TITLE> The SQLJQuery JSP </TITLE> </HEAD> <BODY BGCOLOR="white"> <% String empno = request.getParameter("empno"); if (empno != null) { %> <H3> Employee # <%=empno %> Details: </H3> <%= runQuery(empno) %> <HR><BR> <% } %> <B>Enter an employee number:</B> <FORM METHOD="get"> <INPUT TYPE="text" NAME="empno" SIZE=10> <INPUT TYPE="submit" VALUE="Ask Oracle"); </FORM> </BODY> </HTML> <%! private String runQuery(String empno) throws java.sql.SQLException { DefaultContext dctx = null; String ename = null; double sal = 0.0; String hireDate = null; StringBuffer sb = new StringBuffer(); try { dctx = Oracle.getConnection("jdbc:oracle:oci8:@", "scott", "tiger"); #sql [dctx] { SELECT ename, sal, TO_CHAR(hiredate,'DD-MON-YYYY') INTO :ename, :sal, :hireDate FROM scott.emp WHERE UPPER(empno) = UPPER(:empno) }; sb.append("<BLOCKQUOTE><BIG><B><PRE>\n"); sb.append("Name : " + ename + "\n"); sb.append("Salary : " + sal + "\n"); sb.append("Date hired : " + hireDate); sb.append("</PRE></B></BIG></BLOCKQUOTE>"); } catch (java.sql.SQLException e) { sb.append("<P> SQL error: <PRE> " + e + " </PRE> </P>\n"); } finally { if (dctx!= null) dctx.close(); } return sb.toString(); } %>
This example uses the JDBC OCI driver, which requires an Oracle client installation. The Oracle class used in getting the connection is provided with Oracle SQLJ.
Entering employee number 7788 for the schema used in the example results in the following output:
For further examples of using SQLJ in JSP pages, refer to the OC4J demos.
You can trigger the OC4J JSP translator to invoke the Oracle SQLJ translator in one of two ways:
or:
Either of these results in the JSP translator generating a .sqlj file instead of a .java file. The Oracle SQLJ translator is then invoked to translate the .sqlj file into a .java file.
Using SQLJ results in additional output files; see "Generated Files and Locations".
|
Important:
|
When you execute or pre-translate a SQLJ JSP page, you can specify desired Oracle SQLJ option settings. This is true both in on-demand translation scenarios and pre-translation scenarios, as follows:
sqljcmd configuration parameter. This parameter, in addition to allowing you to specify a particular SQLJ translator executable, allows you to set SQLJ command-line options.
For information about sqljcmd, see "JSP Configuration Parameters".
ojspc pre-translation tool, use the ojspc -S option. This option allows you to set SQLJ command-line options.
For information, see "Command-Line Syntax for ojspc" and "Option Descriptions for ojspc".
This section describes the following Oracle support features for XML:
For information about additional JSP support for XML and XSL that is provided through custom tags, refer to the Oracle9iAS Containers for J2EE JSP Tag Libraries and Utilities Reference.
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 OC4J JSP container does not use this DTD directly or require you to use a jsp:root tag, but the JSP translator includes logic to recognize the alternative syntax specified in the standard DTD. Table 5-1 documents this syntax.
JSP action tags, such as jsp:useBean, generally use syntax that already complies with XML. Changes due to quoting conventions or for request-time attribute expressions may be necessary, however.
The oracle.xml.sql.query.OracleXMLQuery class is provided with Oracle9i and Oracle9iAS as part of the XML-SQL utility for XML functionality in database queries. This class requires file xsu12.jar (or xsu111.jar for JDK 1.1.x), which is also required for XML functionality in some of the custom tags and JavaBeans provided with OC4J. This file is provided with Oracle9i and Oracle9iAS as well.
For a JSP sample using OracleXMLQuery, refer to the OC4J demos.
For information about the OracleXMLQuery class and other XML-SQL utility features, refer to the Oracle9i XML Developer's Kits Guide - XDK.
This section describes some of the JSP runtime functionality, particularly regarding dynamic page retranslation and class reloading, and points out some considerations for optimizing execution. The following topics are covered:
By default, particularly for use in development environments where code is in flux, the JSP container has the following behavior during page execution:
.class file timestamp against the .jsp source file timestamp, and retranslate the page if the .class file is older (indicating that the page has been modified since the page implementation class was loaded).
/WEB-INF/classes directory
/WEB-INF/lib directory
_pages output directory (generated page implementation classes)
See "Classpath Functionality" for related information.
In a typical deployment environment, where source code will not change, comparing timestamps is unnecessary. In this case, you can avoid all timestamp comparisons and any possible retranslation and reloading by setting the JSP main_mode flag to justrun. This will optimize program execution.
If you want to reload modified class files but not retranslate modified JSP pages, you can set main_mode to reload.
For more information about the main_mode flag, see "JSP Configuration Parameters".
include directive), the page that includes it will be automatically retranslated the next time it is invoked. (This is not true in JServ.)
This section describes additional settings you can consider to optimize JSP performance.
By default, a JSP page uses an area of memory known as a page buffer. This buffer (8 KB 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 the output step of copying the buffer.
If a JSP page does not need an HTTP session (essentially, does not need to store or retrieve session attributes), then you can direct that no session be used. Specify this with a page directive such as the following:
<%@ page session="false" %>
This will improve the performance of the page by eliminating the overhead of session creation or retrieval.
Note that although servlets by default do not use a session, JSP pages by default do use a session. For background information, see "Servlet Sessions".
|
 Copyright © 2000, 2002 Oracle Corporation. All Rights Reserved. |
|