7 JSP Translation and Deployment

Features of Page Implementation Class Code

When the JSP translator generates servlet code in the page implementation class, it automatically handles some of the standard programming overhead. For both the on-demand translation model and the pretranslation model, generated code automatically includes the following features:

• It extends a wrapper class provided by the JSP container that implements the javax.servlet.jsp.HttpJspPage interface, which extends the more generic javax.servlet.jsp.JspPage interface, which in turn extends the javax.servlet.Servlet interface.

• It implements the _jspService() method specified by the HttpJspPage interface. This method, often referred to as the "service" method, is the central method of the page implementation class. Code from any Java scriptlets, expressions, and JSP tags in the JSP page is incorporated into this method implementation.

• It includes code to request an HTTP session unless your JSP source code specifically sets session="false" in a page directive.

For introductory information about key JSP and servlet classes and interfaces, see Appendix A, "Servlet and JSP Technical Background".

Member Variables for Static Text

The service method, _jspService(), of the page implementation class includes print statements—out.print() or equivalent calls on the implicit out object—to print any static text in the JSP page. The JSP translator places the static text itself in a series of member variables in the page implementation class. The service method out.print() statements reference these member variables to print the text.

Package Naming

In an on-demand translation scenario, the URL path that is specified when the user requests a JSP page—specifically, the path relative to the document root or application root—determines the package name for the generated page implementation class. Each directory in the URL path represents a level of the package hierarchy.

It is important to note, however, that generated package names are always lowercase, regardless of the case in the URL.

Consider the following URL as an example:

http://host:port/HR/expenses/login.jsp

In the current OC4J JSP implementation, this results in the following package specification in the generated code:

package _hr._expenses;

(Implementation details are subject to change in future releases.)

No package name is generated if the JSP page is at the application root directory, where the URL is as follows:

http://host:port/login.jsp

Class Naming

The base name of the .jsp file determines the class name in the generated code.

Consider the following URL example:

http://host:port/HR/expenses/UserLogin.jsp

In the current OC4J JSP implementation, this yields the following class name in the generated code:

public class _UserLogin extends ...

(Implementation details are subject to change in future releases.)

Be aware that the case (lowercase/uppercase) that users specify in the URL must match the case of the actual .jsp file name. For example, they can specify UserLogin.jsp if that is the actual file name, or userlogin.jsp if that is the actual file name, but not userlogin.jsp if UserLogin.jsp is the actual file name.

Currently, the translator determines the case of the class name according to the case of the file name. For example:

• The file name UserLogin.jsp results in the class _UserLogin.

• The file name Userlogin.jsp results in the class _Userlogin.

• The file name userlogin.jsp results in the class _userlogin.

If you care about the case of the class name, then you must name the .jsp file accordingly. However, because the page implementation class is invisible to the end user, this is usually not a concern.

Files Generated by the JSP Translator

This section lists files that are generated by the JSP translator. For the file name examples, presume a file Foo.jsp is being translated.

Source files:

• A .java file (for example, _Foo.java) is produced for the page implementation class.

Binary files:

• A .class file is produced by the Java compiler for the page implementation class. The Java compiler is the JDK javac by default, but you can specify an alternative compiler using the JSP javaccmd configuration parameter.

• A .res Java resource file (for example, _Foo.res) is optionally produced for the static page content if the external_resource JSP configuration parameter is enabled.

JSP Translator Output File Locations

The JSP translator places generated output files under a _pages directory that is created under the JSP cache directory, which is specified in the jsp-cache-directory attribute of the <orion-web-app> element in either the global-web-application.xml file or the application orion-web.xml file. Here is the general base location if you assume the default "./persistence" value of jsp-cache-directory:

ORACLE_HOME/j2ee/home/app-deployment/app-name/web-app-name/persistence/_pages/...

In OC4J standalone, here is the location relative to where OC4J is installed:

j2ee/home/app-deployment/app-name/web-app-name/persistence/_pages/...

Note the following, and refer to "Key OC4J Configuration Files" for related information about the noted configuration files:

• The app-deployment directory is the OC4J deployment directory specified in the OC4J server.xml file. (In OC4J standalone, this is typically the application-deployments directory.)

• Also, app-name is the application name, according to an <application> element in server.xml.

• And web-app-name is the corresponding "Web application name", mapped to the application name in a <web-app> element in the OC4J Web site XML file (typically default-web-site.xml file in Oracle Application Server or http-web-site.xml in OC4J standalone).

The path under the _pages directory depends on the path of the .jsp file under the application root directory.

As an example, in OC4J standalone, consider the page welcome.jsp in the examples/jsp subdirectory under the OC4J standalone default Web application directory. The path to this page would be as follows, relative to where OC4J is installed:

j2ee/home/default-web-app/examples/jsp/welcome.jsp

Assuming the default application deployment directory, the JSP translator would place the output files ( _welcome.java and _welcome.class) in the following directory:

j2ee/home/application-deployments/default/defaultWebApp/persistence/_pages/_examples/_jsp

Because the .jsp source file is in the examples/jsp subdirectory under the application root directory, the JSP translator generates _examples._jsp as the package name and places the output files into an _examples/_jsp subdirectory under the _pages directory.

Note the following for OC4J standalone:

• The application-deployments directory is the OC4J default deployment directory.

• Also, default is the OC4J default application name and defaultWebApp is the default Web application name, both used for JSP pages placed in the default-web-app directory.

The ojsp-global-include.xml File

The ojsp-global-include.xml file specifies the names of files to include, whether they should be included at the tops or bottoms of JSP pages, and the locations of JSP pages to which the global includes should apply. This section describes the elements of ojsp-global-include.xml.

<include>

<into>

Global Include Examples

This section provides examples of global includes.

<?xml version="1.0" standalone='yes'?>
<!DOCTYPE ojsp-global-include SYSTEM 'ojsp-global-include.dtd'>

<ojsp-global-include>
  <include file="/header.html">
     <into directory="/dir1" />
  </include>
  <include file="/footer1.html" position="bottom">
     <into directory="/dir1" subdir="false" />
     <into directory="/dir1/part1/" subdir="false" />
  </include>
  <include file="/footer2.html" position="bottom">
     <into directory="/dir1/part2/" subdir="false" />
  </include>
</ojsp-global-include>

<?xml version="1.0" standalone='yes'?>
<!DOCTYPE ojsp-global-include SYSTEM 'ojsp-global-include.dtd'>

<ojsp-global-include>
  <include file="/WEB-INF/nls/params.jsf">
     <into directory="/" />
  </include>   
</ojsp-global-include>

<% request.setCharacterEncoding(response.getCharacterEncoding()); %>

<%@ include file="/WEB-INF/nls/parms.jsf" %>

-addclasspath

(fully qualified path; ojspc default: empty)

Use this option to specify additional classpath entries for javac to use when compiling generated page implementation class source. Otherwise, javac uses only the system classpath.

-appRoot

(fully qualified path; ojspc default: current directory)

Use this option to specify an application root directory. The default is your current directory when you ran ojspc.

The specified application root directory path is used as follows:

• For static include directives in the page being translated

  The specified directory path is prepended to any application-relative (context-relative) paths in the include directives of the translated page.

• In determining the package of the page implementation class

  The package will be based on the location of the file being translated relative to the application root directory. The package, in turn, determines the placement of output files. (See "Summary of ojspc Output Files, Locations, and Related Options".)

This option is necessary, for example, so that included files can still be found if you run ojspc from some other directory.

Consider the following example.

• You want to translate the following file:

  /abc/def/ghi/test.jsp
  
  

• You run ojspc from the current directory, /abc, as follows (where % is a UNIX prompt):

  % cd /abc
  % ojspc def/ghi/test.jsp
  
  

• The test.jsp page has the following include directive:

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

• The test2.jsp page is in the /abc directory, as follows:

  /abc/test2.jsp 
  
  

This example requires no -appRoot setting because the default application root setting is the current directory, which is the /abc directory. The include directive uses the application-relative /test2.jsp syntax (note the beginning "/"), so the included page will be found as /abc/test2.jsp.

The package in this case is _def._ghi, based on the location of test.jsp relative to the current directory when you ran ojspc. (The current directory is the default application root.) Output files are placed accordingly.

If, however, you run ojspc from some other directory, suppose /home/mydir, then you would need an -appRoot setting as in the following example:

% cd /home/mydir
% ojspc -appRoot /abc /abc/def/ghi/test.jsp

The package is still _def._ghi, based on the location of test.jsp relative to the specified application root directory.

-batchMask

(file masks to batch-process in archive; ojspc default: see description)

For batch pretranslation, you can use this option to specify source files to process in an archive file. By default, all .jsp and .java files are processed. File masks specified through the -batchMask option are used instead of (not in addition to) these defaults.

Place quotes around the list of file masks and use commas or semicolons as delimiters within the list. White space before or after a file mask is ignored. You can include directories in the mask.

The -batchMask implementation includes complete support for standard wildcard pattern-matching.

Given the default setting, the following two examples are equivalent:

% ojspc myapp.war

% ojspc -batchMask "*.jsp,*.java" myapp.war

This next example drops processing for .java files while adding processing for .jspf and .jsph files:

% ojspc -batchMask "*.jspf,*.jsph,*.jsp" myapp.war

The following example does not process.java files, and only processes .jsp files whose names start with "abc" and who are in subdirectories under the top level of the archive file:

% ojspc -batchMask "*/abc*.jsp" myapp.zip

The following example is the same as the preceding example, but also processes .jsp files whose names start with "abc" in the top level of the archive file:

% ojspc -batchMask "abc*.jsp, */abc*.jsp" myapp.jar

This final example specifically processes the file a.jspc, as well as any .jsp files that start with "My" and are in a directory that is a subdirectory of mydir/subdir and matches the pattern "t?st" (any character as the second character, such as "test", "tast", or "tust"):

% ojspc -batchMask "mydir/subdir/t?st/My*.jsp, a.jspc" myapp.ear

-deleteSource

(boolean; ojspc default: false)

For batch pretranslation, enable this flag if you do not want processed source files to appear in the resulting archive file. This is .jsp and .java files by default, or else only the files that match the file mask in the -batchMask option. Generated .java files are also discarded, as usual.

If you do not use the -output option, then the contents of the original archive file are overwritten to remove any processed source files after processing. If you do use the -output option, then processed source files will not be copied to the specified output archive file. (The original archive file is unaltered.)

-dir

(fully qualified path; ojspc default: current directory)

Use this option to specify a base directory for ojspc placement of generated binary files—.class files and Java resource files. (The .res files produced for static content by the -extres option are Java resource files.) As a shortcut, -d is also accepted.

The specified path is taken as a file system path (not an application-relative or page-relative path), and the directory must already exist.

Subdirectories under the specified directory are created automatically, as appropriate, depending on the package. See "Summary of ojspc Output Files, Locations, and Related Options" for more information.

The default is to use the current directory (your current directory when you executed ojspc).

It is recommended that you use this option to place generated binary files into a clean directory so that you easily know what files have been produced.

-extend

(fully qualified Java class name; ojspc default: empty)

Use this option to specify a Java class that the generated page implementation class will extend.

-extraImports

(import list; ojspc default: empty)

As described in "Default Package Imports", the OC4J JSP container has a smaller default list of packages that are imported into each JSP page than was the case prior to Oracle9iAS Release 2 (9.0.3). This is in accordance with the JSP specification. You can avoid updating your code, however, by specifying package names or fully qualified class names for any additional imports through the -extraImports option. Be aware that the names must be in quotes, and either comma-delimited or semicolon-delimited, as in the following example:

% ojspc -extraImports "java.util.*,java.io.*" foo.jsp

-extres

(boolean; ojspc default: false)

Enabling this flag instructs ojspc to place static content of the page into a Java resource file instead of into the service method of the generated page implementation class.

The resource file name is based on the JSP page name. In the current OC4J JSP implementation, it will be the same core name as the JSP name (unless special characters are included in the JSP name), but with an underscore ("_") prefix and .res suffix. Translation of MyPage.jsp, for example, would create _MyPage.res in addition to normal output. The exact implementation for name generation might change in future releases, however.

The resource file is placed in the same directory as output .class files.

If there is a lot of static content in a page, this technique will speed translation and might speed execution of the page. For more information, see "Workarounds for Large Static Content or Significant Tag Library Usage".

-forgiveDupDirAttr

(boolean; ojspc default: false)

Enabling this flag avoids translation errors in JSP 1.2 (or higher) if you have duplicate settings for the same directive attribute within a single JSP translation unit (a JSP page plus anything it includes through include directives).

The JSP specification directs that a JSP container must verify that directive attributes, with the exception of the page directive import attribute, are not set more than once each within a single JSP translation unit. See "Duplicate Settings of Page Directive Attributes Are Disallowed" for more information.

The JSP 1.1 specification did not specify such a limitation. OC4J offers the -forgiveDupDirAttr option for backward compatibility.

-help

(boolean; ojspc default: false)

Use this option to have ojspc display usage information and then exit. As a shortcut, -h is also accepted.

-implement

(fully qualified Java interface name; ojspc default: empty)

Use this option to specify a Java interface that the generated page implementation class will implement.

-noCompile

(boolean; ojspc default: false)

Enabling this flag directs ojspc to not compile the generated page implementation class Java source. This is in case you want to compile it later for some reason, such as with an alternative Java compiler.

-noTldXmlValidate

(boolean; ojspc default: false)

Enable this flag if you do not want XML validation of tag library descriptor (TLD) files of the application. By default, validation of TLD files is performed.

See "Overview of TLD File Validation and Features" for related information.

-oldIncludeFromTop

(boolean; ojspc default: false)

This is for backward compatibility with Oracle JSP versions prior to Oracle9iAS Release 2, for functionality of include directives. If you enable this flag, page locations in nested include directives are relative to the top-level page. Otherwise, page locations are relative to the immediate parent page, which complies with the JSP specification.

-output

(archive file name; ojspc default: none)

For batch pretranslation, use the -output option if you want to specify a new archive file for output instead of updating the original archive file. In this case, all contents of the original archive file are copied into the specified archive file, then the output .class files and any resource files from pretranslation are placed into a nested JAR file within the specified file (and source files are deleted from the specified file if -deleteSource is enabled). The original archive file is unaltered and you would use the new file instead of the original file for deployment. (See "Overview of ojspc Batch Pretranslation" for information about the nested JAR file.)

Without the -output option, the original archive file is updated; no new archive file is created.

Here is an example of -output usage:

% ojspc -output myappout.war myapp.war

-packageName

(fully qualified package name; ojspc default: per .jsp file location)

Use this option to specify a package name for the generated page implementation class, using Java "dot" syntax.

Without setting this option, the package name is determined according to the location of the .jsp file relative to your current directory when you ran ojspc.

Consider an example where you run ojspc from the /myapproot directory, while the .jsp file is in the /myapproot/src/jspsrc directory (where % is a UNIX prompt):

% cd /myapproot
% ojspc -packageName myroot.mypackage src/jspsrc/Foo.jsp

This results in myroot.mypackage being used as the package name.

If this example did not use the -packageName option, the JSP translator (in its current implementation) would use _src._jspsrc as the package name by default. (Be aware that such implementation details are subject to change in future releases.)

-reduceTagCode

(boolean; ojspc default: false)

The Oracle JSP implementation reduces the size of generated code for custom tag usage, but enabling this flag results in even further size reduction. There might be performance consequences regarding tag handler reuse, however. See "Tag Handler Code Generation".

-reqTimeIntrospection

(boolean; ojspc default: false)

Enabling this flag allows request-time JavaBean introspection whenever compile-time introspection is not possible. When compile-time introspection is possible and succeeds, however, there is no request-time introspection regardless of the setting of this flag.

As a sample scenario for request-time introspection, assume a tag handler returns a generic java.lang.Object instance in the VariableInfo instance of the tag-extra-info class during translation and compilation, but actually generates more specific objects during request-time (runtime). In this case, if -reqTimeIntrospection is enabled, the JSP container will delay introspection until request-time. (See "Scripting Variables, Declarations, and Tag-Extra-Info Classes" for information about use of VariableInfo.)

An additional effect of this flag is to allow a bean to be declared twice, such as in different branches of an if..then..else loop. Consider the example that follows. Without -reqTimeIntrospection being enabled, this code would cause a parse exception. With it enabled, the code will work without error:

<% if (cond) { %> 
      <jsp:useBean id="foo" class="pkgA.Foo1" /> 
<% } else { %> 
      <jsp:useBean id="foo" class="pkgA.Foo2" /> 
<% } %>

-srcdir

(fully qualified path; ojspc default: current directory)

Use this option to specify a base directory location for ojspc placement of generated source files (.java files).

The specified path is taken simply as a file system path, not an application-relative or page-relative path. The directory must already exist.

Subdirectories under the specified directory are created automatically, as appropriate, depending on the package. See "Summary of ojspc Output Files, Locations, and Related Options" for more information.

The default is to use the current directory (your current directory when you executed ojspc).

It is recommended that you use this option to place generated source files into a clean directory so that you conveniently know what files have been produced.

-staticTextInChars

(boolean; ojspc default: false)

Enabling this flag directs the JSP translator to generate static text in JSP pages as characters instead of bytes. The default setting is false, which improves performance in outputting static text blocks.

Enable this flag if your application requires the ability to change the character encoding dynamically during runtime, such as in the following example:

<% response.setContentType("text/html; charset=UTF-8"); %>

-tagReuse

(mode for tag handler reuse; ojspc default: runtime)

Use this option to specify the mode of tag handler reuse (tag handler instance pooling), as follows:

• Use the setting none to disable tag handler reuse. You can override this in any particular JSP page by setting the JSP page context attribute oracle.jsp.tags.reuse to a value of true.

• Use the default setting runtime to enable the runtime model of tag handler reuse. You can override this in any particular JSP page by setting the JSP page context attribute oracle.jsp.tags.reuse to a value of false.

• Use the setting compiletime to enable the compile-time model of tag handler reuse in its basic mode.

• Use the setting compiletime_with_release to enable the compile-time model of tag handler reuse in its "with release" mode, where the tag handler release() method is called between usages of a given tag handler within a given page.

See "Disabling or Enabling Runtime or Compile-Time Tag Handler Reuse" for more information about tag handler reuse.

-verbose

(boolean; ojspc default: false)

Enabling this flag directs ojspc to report its translation steps as it executes.

The following example shows -verbose output for the translation of myerror.jsp. (In this example, ojspc is run from the directory where myerror.jsp is located; assume % is a UNIX prompt.)

% ojspc -verbose myerror.jsp
Translating file: myerror.jsp
1 JSP files translated successfully.
Compiling Java file: ./_myerror.java

-version

(boolean; ojspc default: false)

Use this option to have ojspc display the JSP version number and then exit.

-xmlValidate

(boolean; ojspc default: false)

Enable this flag if you want XML validation of the application web.xml file. Because the Tomcat JSP reference implementation does not perform XML validation, this flag is disabled by default.

OC4J Deployment Features

In OC4J, deploy each application through a standard EAR (Enterprise archive) file. The name of the application and the name and location of the EAR file are specified through an <application> element in the OC4J server.xml file. This file is in the OC4J configuration files directory.

In an Oracle Application Server environment, use Enterprise Manager for deployment and configuration and do not update server.xml or other configuration files directly. Refer to the Oracle Application Server Containers for J2EE User's Guide for information.

In an OC4J standalone development environment, OC4J supports the admin.jar tool for deployment. This modifies server.xml, http-web-site.xml, and other configuration files for you, based on settings you specify to the tool. Or you can modify the configuration files manually (not generally recommended). Note that if you modify configuration files in Oracle Application Server without going through Enterprise Manager, you must run the dcmctl tool, using its updateConfig command, to inform Oracle Application Server Distributed Configuration Management (DCM) of the updates. (This does not apply in an OC4J standalone mode, where OC4J is being run apart from Oracle Application Server.)

The dcmctl tool is documented in the Oracle Application Server Administrator's Guide.

The EAR file includes the following:

• A standard application.xml configuration file, in /META-INF

• Optionally, an orion-application.xml configuration file, in /META-INF

• A standard WAR (Web archive) file

The WAR file includes the following:

• A standard web.xml configuration file, in /WEB-INF

  In the web.xml file for any particular application, you can override global settings for individual configuration parameters or for the definition of the JSP servlet (oracle.jsp.runtimev2.JspServlet by default). Each application uses its own instance of the JSP servlet.

• Optionally, an orion-web.xml configuration file, in /WEB-INF

• Classes necessary to run the application (servlets, JavaBeans, and so on), under /WEB-INF/classes and in JAR files in /WEB-INF/lib

• JSP pages and static HTML files

See the Oracle Application Server Containers for J2EE User's Guide for more information about deployment to Oracle Application Server. See the Oracle Application Server Containers for J2EE Stand Alone User's Guide for deployment to a standalone environment and for information about admin.jar. Also see "Key OC4J Configuration Files" for a summary of important configuration files in OC4J.

Standard WAR Deployment

The JSP specification (since JSP 1.1) supports the packaging and deployment of Web applications, including JavaServer Pages, according to the servlet specification (since servlet 2.2).

In typical implementations, you can deploy JSP pages through the WAR mechanism, creating WAR files through the JAR utility. The JSP pages can be delivered in source form and are deployed along with any required support classes and static HTML files.

According to the servlet specification, a Web application includes a deployment descriptor file, web.xml, that contains information about the JSP pages and other components of the application. The web.xml file must be included in the WAR file.

The servlet specification also defines an XML DTD for web.xml deployment descriptors and specifies exactly how a servlet container must deploy a Web application to conform to the deployment descriptor.

Through these logistics, a WAR file is the best way to ensure that a Web application is deployed into any standard servlet environment exactly as the developer intends.

Deployment configurations in the web.xml deployment descriptor include mappings between servlet paths and the JSP pages and servlets that will be invoked. You can specify many additional features in web.xml as well, such as timeout values for sessions, mappings of file name extensions to MIME types, and mappings of error codes to JSP error pages.

For more information about standard WAR deployment, see the Sun Microsystems Java Servlet Specification.

Techniques for Page Pretranslation with ojspc

When you pretranslate with ojspc (not considering batch pretranslation), use the -dir option to set an appropriate output base directory for placement of generated binary files.

Consider the example in "JSP Translator Output File Locations", where the JSP page is located in the examples/jsp subdirectory under the OC4J standalone default Web application directory:

j2ee/home/default-web-app/examples/jsp/welcome.jsp

A user would invoke this with a URL such as the following:

http://host:port/examples/jsp/welcome.jsp

(This is just a general example and does not consider OC4J configuration for the context path.)

In an on-demand translation scenario for this page, as explained in the example, the JSP translator would by default use the following base directory for placement of generated binary files:

j2ee/home/application-deployments/default/defaultWebApp/persistence/_pages/_examples/_jsp

When you pretranslate, set your current directory to the application root directory, then in ojspc set the _pages directory as the output base directory. This results in the appropriate package name and file hierarchy. Continuing the example (where % is a UNIX prompt, OC4J_HOME is the directory where OC4J is installed, and the ojspc command wraps around to a second line):

% cd OC4J_HOME/j2ee/home/default-web-app
% ojspc examples/jsp/welcome.jsp 
-dir OC4J_HOME/j2ee/home/application-deployments/default/defaultWebApp/persistence/_pages

(This assumes you specify the appropriate OC4J_HOME directory.) The ojspc command translates examples/jsp/welcome.jsp and specifies the _pages directory as the base output directory.

The URL noted above specifies an application-relative path of examples/jsp/welcome.jsp, so at execution time the JSP container looks for the binary files in an _examples/_jsp subdirectory under the _pages directory. This subdirectory would be created automatically by ojspc if it is run as in the above example.

At execution time, the JSP container would find the pretranslated binaries and would not have to perform translation, assuming that either the source file was not altered after pretranslation, or the JSP main_mode flag is set to justrun.

Batch Pretranslation with ojspc

There are ojspc features for batch pretranslation of JSP files in archive files (JAR, WAR, EAR, or ZIP files). When you specify an archive file on the ojspc command line, by default all .jsp and .java files in the contents will be pretranslated and compiled, as appropriate, and the archive file will be updated to include the output .class files and any Java resource files (but not generated .java files). You would then deploy the resulting archive file.

In addition to this basic functionality, you can use key ojspc options as follows:

• You can use the -batchMask option to specify file name extensions for pretranslation and compilation. Whatever you specify is instead of the defaults (*.jsp and *.java).

• You can use the -output option to specify a new archive file name. By default, ojspc updates the original archive file, adding output .class files and any resource files (and possibly deleting processed source files, according to the -deleteSource option). If you want to be sure that the original archive file is unaltered, then enable the -output option. In this case, all contents of the original archive file are copied into the specified archive file, then the specified file is updated instead of the original file. The original archive file is unaltered, and you would use the new file instead of the original file for deployment.

• You can use the -deleteSource option if you do not want processed source files to appear in the resulting archive file. If you do not also use the -output option, this effectively means that all processed source files are removed from the original archive file after processing. If you do not use the -batchMask option, this consists of all .jsp and .java files. Otherwise, this consists of all files specified in the -batchMask setting.

Standard JSP Pretranslation without Execution

It is also possible to specify JSP pretranslation without execution when you invoke the page in an on-demand scenario. Accomplish this as follows:

1. Enable the JSP precompile_check configuration parameter. (See "JSP Configuration Parameters".)

2. Enable the standard jsp_precompile request parameter when you invoke the JSP page from the browser.

Following is an example of using jsp_precompile:

http://host:port/foo.jsp?jsp_precompile=true

or:

http://host:port/foo.jsp?jsp_precompile

(The "=true" is optional.)

Refer to the Sun Microsystems JavaServer Pages Specification for more information about this mode of operation.

Archiving and Deploying the Binary Files

You must take steps to create and archive the binary files in an appropriate hierarchy.

• If you pretranslate with ojspc, you must first set your current directory to the application root directory. After running ojspc, archive the output files using the ojspc output directory as the base directory for the archive. See "The ojspc Pretranslation Utility" for general information about this utility.

• If you are archiving binary files produced during previous execution in an on-demand translation environment, then archive the output directory structure, typically under the _pages directory.

In the target environment, place the archive JAR file in the /WEB-INF/lib directory. Alternatively, restore the archived directory structure under the appropriate directory, typically under the _pages directory.

Configuring the OC4J JSP Container for Execution with Binary Files Only

If you have deployed binary files to an OC4J environment, set the JSP configuration parameter main_mode to the value justrun or reload to execute JSP pages without the original source.

Without this setting, the JSP translator will always look for the JSP source file to see if it has been modified more recently than the page implementation .class file, and will terminate with a "file not found" error if it cannot find the source file.

With main_mode set appropriately, the user can invoke a page with the same URL that would be used if the source file were in place.

For how to set configuration parameters in the OC4J environment, see "Setting JSP Configuration Parameters in OC4J".