Skip Headers

Oracle9iAS Containers for J2EE Support for JavaServer Pages Developer's Guide
Release 2 (9.0.3)
Part Number A97679-01
Go To Core Documentation
Core		 Go To Platform Documentation
Platform		 Go To Table Of Contents
Contents		 Go To Index
Index

Go to previous page Go to next page

3
Getting Started

This chapter covers basic issues in your JSP environment, including key support files, key OC4J configuration files, and configuration of the JSP container. It also discusses initial considerations such as application root functionality, classpath functionality, security issues, and file naming conventions.

Before getting started, it is assumed that you can do the following on your system:

The following topics are covered here:

Notes:

JSP pages will run with any standard browser supporting HTTP 1.0 or higher. The JDK or other Java environment in the end-user's Web browser is irrelevant, because all the Java code in a JSP page is executed in the Web server.

Some Initial Considerations

This section discusses some initial considerations you should be aware of before you begin coding or using JSP pages:

Application Root Functionality

The servlet 2.2 and 2.3 specifications provide for each Web application to have its own servlet context. Each servlet context is associated with a directory path in the server file system, which is the base path for modules of the Web application. This is the application root. Each Web application has its own application root. For a Web application in a servlet 2.2 or 2.3 environment, servlets, JSP pages, and static files such as HTML files are all based out of this application root. (By contrast, in servlet 2.0 environments the application root for servlets and JSP pages is distinct from the doc root for static files.)

Note that a servlet URL has the following general form: 

http://host[:port]/contextpath/servletpath

When a servlet context is created, a mapping is specified between the application root and the context path portion of a URL. The servlet path is defined in the application web.xml file. The <servlet> element within web.xml associates a servlet class with a servlet name. The <servlet-mapping> element within web.xml associates a URL pattern with a named servlet. When a servlet is executed, the servlet container will compare a specified URL pattern with known servlet paths, and pick the servlet path that matches. See the Oracle9iAS Containers for J2EE Servlet Developer's Guide for more information.

For example, consider an application with the application root /home/dir/mybankapp/mybankwebapp, which is mapped to the context path /mybank. Further assume the application includes a servlet whose servlet path is loginservlet. You can invoke this servlet as follows: 

http://host[:port]/mybank/loginservlet

The application root directory name itself is not visible to the end-user.

To continue this example for an HTML page in this application, the following URL points to the file /home/dir/mybankapp/mybankwebapp/dir1/abc.html: 

http://host[:port]/mybank/dir1/abc.html

For each servlet environment there is also a default servlet context. For this context, the context path is simply "/", which is mapped to the default servlet context application root. For example, assume the application root for the default context is /home/dir/defaultapp/defaultwebapp, and a servlet with the servlet path myservlet uses the default context. Its URL would be as follows: 

http://host[:port]/myservlet

The default context is also used if there is no match for the context path specified in a URL.

Continuing this example for an HTML file, the following URL points to the file /home/dir/defaultapp/defaultwebapp/dir2/def.html: 

http://host[:port]/dir2/def.html

Classpath Functionality

The JSP container uses standard locations on the Web server to look for translated JSP pages, as well as.class files and .jar files for any required classes (such as JavaBeans). The container will find files in these locations without any Web server classpath configuration, and has the ability to automatically reload classes in these locations, depending on configuration settings.

The locations for dependency classes are as follows and are relative to the application root: 

/WEB-INF/classes/...
/WEB-INF/lib

The location for JSP page implementation classes (translated pages) is as follows: 

.../_pages/...

The /WEB-INF/classes directory is for individual Java .class files. You should store these classes in subdirectories under the classes directory, according to Java package naming conventions. For example, consider a JavaBean called LottoBean whose code defines it to be in the oracle.jsp.sample.lottery package. The JSP container will look for LottoBean.class in the following location relative to the application root: 

/WEB-INF/classes/oracle/jsp/sample/lottery/LottoBean.class

The lib directory is for .jar files. Because Java package structure is specified in the .jar file structure, the .jar files are all directly in the lib directory (not in subdirectories). As an example, LottoBean.class might be stored in lottery.jar, located as follows relative to the application root: 

/WEB-INF/lib/lottery.jar

The _pages directory is under the J2EE home directory in OC4J. In Oracle9iAS, OC4J directory paths are configurable; in OC4J standalone, by default it would be as follows: 

[Oracle_Home]/j2ee/home/application-deployments/app-name/web-app-name/temp

The app-name is determined through an <application> element in the OC4J server.xml file; the web-app-name, which corresponds to the WAR file name, is mapped to the app-name through a <web-app> element in the OC4J default-web-site.xml file (or other Web site XML file). See the Oracle9iAS Containers for J2EE User's Guide and the Oracle9iAS Containers for J2EE Servlet Developer's Guide for more information.

Generated page implementation classes for translated JSP pages are placed in subdirectories under the _pages directory according to the locations of the original .jsp files. See "Generated Files and Locations" for information.

Important:

Implementation details, such as the location of the _pages directory, are subject to change in future releases.

JSP Security Considerations

With respect to application security, be aware of the following:

Default Package Imports

Beginning with Oracle9iAS release 2 (9.0.3), the OC4J JSP container by default imports the following packages into any JSP page, in accordance with the JSP specification. No page directive import settings are required: 

javax.servlet.*
javax.servlet.http.*
javax.servlet.jsp.*

In previous releases, the following packages were also imported by default: 

java.io.*
java.util.*
java.lang.reflect.*
java.beans.*

The default list of packages to import was reduced to minimize the chance of a conflict between any unqualified class name you might use and a class by the same name in any of the imported packages.

However, this might result in migration problems for applications you have used with previous versions of OC4J. Such applications might no longer compile successfully. If you need imports beyond the default list, you have two choices:

JSP File Naming Conventions

The file name extension .jsp for JSP pages is required by the Sun Microsystems Java Servlet Specification, Version 2.3. The servlet 2.3 specification does not, however, distinguish between complete, translatable pages and page fragments, such as files brought in through an include directive (as described in "Directives").

The JSP 1.2 specification recommends the following:

Key Support Files Provided with OC4J

This section summarizes JAR and ZIP files that are used by the JSP container or JSP applications. These files are installed on your system and into your classpath with OC4J.

Note:

Some of the .jar files here, such as for JDBC and SQLJ, also have .zip alternatives.

There are also files relating to particular areas, such as particular tag libraries. These include the following:

JSP Configuration in OC4J

This section covers the following topics regarding configuration of the JSP environment:

Notes:

  • Discussion of OC4J configuration files and configuration parameters, and how to update them manually, generally assumes an OC4J standalone environment. This is typical during development. For information about JSP configuration through Oracle Enterprise Manager in an Oracle9iAS environment, such as for production deployment, see "JSP Configuration in Oracle Enterprise Manager".

  • For non-OC4J environments, including JServ, use the old oracle.jsp.JspServlet front-end servlet instead of the oracle.jsp.runtimev2.JspServlet version. See "Getting Started in a JServ Environment".

JSP Container Setup

The JSP container is appropriately preconfigured in OC4J. The following settings appear in the OC4J global-web-application.xml file to map the name of the front-end JSP servlet, and to map the appropriate file name extensions for JSP pages: 

<orion-web-app ... >
   ...
   <web-app>
       ...
      <servlet>
         <servlet-name>jsp</servlet-name>
         <servlet-class>oracle.jsp.runtimev2.JspServlet</servlet-class>
         ...
            init_params
         ...
      </servlet>
      ...
      <servlet-mapping>
         <servlet-name>jsp</servlet-name>
         <url-pattern>/*.jsp</url-pattern>
      </servlet-mapping>
      <servlet-mapping>
          <servlet-name>jsp</servlet-name>
          <url-pattern>/*.JSP</url-pattern>
       </servlet-mapping>
       <servlet-mapping>
           <servlet-name>jsp</servlet-name>
           <url-pattern>/*.sqljsp</url-pattern>
       </servlet-mapping>
      <servlet-mapping>
           <servlet-name>jsp</servlet-name>
           <url-pattern>/*.SQLJSP</url-pattern>
      </servlet-mapping>

      ...
   </web-app>
   ...
</orion-web-app>

See the Oracle9iAS Containers for J2EE Servlet Developer's Guide for more information about the global-web-application.xml file.

JSP Configuration Parameters

The JSP front-end servlet in OC4J, oracle.jsp.runtimev2.JspServlet, supports a number of configuration parameters to control JSP operation. This section describes those parameters. There is a summary table, followed by more complete descriptions, and documentation of how to set them in the OC4J global-web-application.xml or orion-web.xml file.

JSP Configuration Parameter Summary Table

Table 3-1 summarizes the configuration parameters supported by JspServlet. For each parameter, the table notes any equivalent ojspc translation options for pages you are pre-translating, and whether the parameter is for runtime or compile-time use.

Notes:

See "The ojspc Pre-Translation Utility" for a description of the ojspc options.

Table 3-1 JSP Configuration Parameters, OC4J Environment  
Parameter Related ojspc Options Description Default Runtime / Compile-
Time

check_page_scope

(n/a)

Set this boolean to true to enable page-scope checking by JspScopeListener (OC4J only).

false

runtime

debug_mode

(n/a)

Set this boolean to true to print the stack trace when a runtime exception occurs.

false

runtime

emit_debuginfo

-debug

Set this boolean to true to generate a line map to the original .jsp file for debugging (for development).

false

compile-time

external_resource

-extres

Set this boolean to true to place all static content of the page into a separate Java resource file during translation.

false

compile-time

extra_imports

-extraImports

Use this to add imports beyond the JSP defaults.

null

compile-time

forgive_dup_dir_attr

-forgiveDupDirAttr

Set this boolean to true to avoid JSP 1.2 translation errors if you have duplicate settings for the same directive attribute within a single JSP translation unit.

false

compile-time

javaccmd

-noCompile

Use this if you want to specify a javac command line, or if you want to specify an alternative Java compiler, optionally with command-line settings (for development). If you specify an alternative compiler, it will be spawned in a separate JVM. Use a null setting for the JDK javac with default settings.

null

compile-time

main_mode

(n/a)

This determines whether classes are automatically reloaded or JSP pages are automatically recompiled, in case of changes. Possible settings are justrun, reload, and recompile.

recompile

runtime

no_tld_xml_validate

-noTldXmlValidate

Set this boolean to true to not perform XML validation of TLD files. By default, validation of TLD files is performed.

false

compile-time

old_include_from_top

-oldIncludeFromTop

Set this boolean to true for page locations in nested include directives to be relative to the top-level page, for backward compatibility with behavior prior to Oracle9iAS release 2.

false

compile-time

precompile_check

(n/a)

Set this boolean to true to check the HTTP request for a standard jsp_precompile setting.

false

runtime

reduce_tag_code

-reduceTagCode

Set this boolean to true for further reduction in the size of generated code for custom tag usage.

false

compile-time

req_time_introspection

-reqTimeIntrospection

Set this boolean to true to enable request-time JavaBean introspection whenever compile-time introspection is not possible.

false

compile-time

sqljcmd

-S

Use this if you want to specify a SQLJ command line, or if you want to specify an alternative SQLJ translator, optionally with command-line settings (for development). If you specify an alternative translator, it will be spawned in a separate JVM. Use a null setting for the Oracle SQLJ version provided with Oracle9iAS, with its default option settings.

null

compile-time

static_text_in_chars

-staticTextInChars

Set this boolean to true to instruct the JSP translator to generate static text in JSP pages as characters instead of bytes.

false

compile-time

tags_reuse_default

(n/a)

This specifies the mode for JSP tag handler reuse: runtime for the runtime model, compiletime or compiletime_with_release for the compile-time model, or none to disable tag handler reuse.

runtime

either

well_known_taglib_loc

(n/a)

This specifies a directory where tag library JAR files can be placed for sharing across multiple Web applications. The default location is j2ee/home/jsp/lib/taglib/ under the [Oracle_Home] directory.

(See description column.)

compile-time

xml_validate

-xmlValidate

Set this boolean to true to perform XML validation of the web.xml file. By default, validation of web.xml is not performed.

false

compile-time

JSP Configuration Parameter Descriptions

This section describes the JSP configuration parameters for OC4J in more detail.

check_page_scope

(boolean; default: false)

For OC4J environments, set this parameter to true to enable Oracle-specific page-scope checking by the JspScopeListener utility. It is false by default for performance reasons.

This parameter is not relevant for non-OC4J environments. For JServ, Oracle-specific page-scope checking is always enabled. For other environments, the Oracle-specific implementation is not used and you must use the checkPageScope custom tag for JspScopeListener page-scope functionality. See "JspScopeListener for Event-Handling" for a brief overview of this utility. See Oracle9iAS Containers for J2EE JSP Tag Libraries and Utilities Reference for detailed information.

debug_mode

(boolean; default: false)

Use the default true setting to print a stack trace whenever a runtime exception occurs. A false setting disables this feature.

Important:

When debug_mode is false and a file is not found, the full path of the missing file is not displayed. This is an important security consideration if you want to suppress the display of the physical file path when non-existent JSP files are requested.

emit_debuginfo

(boolean; default: false)

During development, set this flag to true to instruct the JSP translator to generate a line map to the original .jsp file for debugging. Otherwise, lines will be mapped to the generated page implementation class .java file.

Notes:

  • Oracle9i JDeveloper enables emit_debuginfo.

  • For pre-translating pages, the ojspc -debug option is equivalent.

external_resource

(boolean; default: false)

Set this flag to true to instruct the JSP translator to place generated static content (the Java print commands that output static HTML code) 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, with the .res suffix. With Oracle9iAS release 2, translation of MyPage.jsp, for example, would create _MyPage.res in addition to normal output. (The exact implementation might change in future releases.)

The translator places the resource file into the same directory as generated class files.

If there is a lot of static content in a page, this technique will speed translation and may speed execution of the page. For more information, see "Workarounds for Large Static Content in JSP Pages".

Note:

For pre-translating pages, the ojspc -extres option is equivalent.

extra_imports

(import list; default: null)

As described in "Default Package Imports", as of Oracle9iAS release 2 (9.0.3), the OC4J JSP container has a smaller default list of packages that are imported into each JSP page. 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 extra_imports configuration parameter. See "Setting JSP Configuration Parameters in OC4J" for general syntax, and be aware that the names can be either comma-delimited or space-delimited. Either of the following is okay, for example: 

   <init-param>
      <param-name>extra_imports</param-name>
      <param-value>java.util.* java.beans.*</param-value>
   </init-param>

or: 

   <init-param>
      <param-name>extra_imports</param-name>
      <param-value>java.util.*,java.beans.*</param-value>
   </init-param>

Note:

  • For pre-translating pages, the ojspc -extraImports option is equivalent.

  • As an alternative to using extra_imports, you can use global includes. See "Oracle JSP Global Includes".

forgive_dup_dir_attr

(forgive duplicate directive attributes; default: false)

Set this boolean to true to avoid 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 1.2 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 does not specify such a limitation. OC4J offers the forgive_dup_dir_attr parameter for backward compatibility.

Note:

For pre-translating pages, the ojspc -forgiveDupDirAttr option is equivalent.

javaccmd

(compiler executable and options; default: null)

This parameter is useful during development in any of the following circumstances:

Specifying an alternative compiler results in that executable being spawned as a separate process in a separate JVM, instead of within the same JVM as the JSP container. You can fully specify the path for the executable, or specify only the executable and let the JSP container look for it in the system path.

For example, set javaccmd to the value javac -verbose to run the compiler in verbose mode.

Notes:

  • The specified Java compiler must be installed in the classpath, and any front-end utility (if applicable) must be installed in the system path.

  • For pre-translating pages, the ojspc -noCompile option allows similar functionality. It results in no compilation by javac, so you can compile the translated classes manually, using any desired compiler.

main_mode

(mode switch for reloading or recompilation; default: recompile)

This is a flag to direct the mode of operation of the JSP container, particularly for automatic recompilation of JSP pages and reloading of Java classes that have changed.

Here are the supported settings:

no_tld_xml_validate

(disabling of XML validation of TLD files; default: false)

Set this to true to disable XML validation of the 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.

Note:

For pre-translating pages, the ojspc -noTldXmlValidate option is equivalent.

old_include_from_top

(backward compatibility for include; default: false)

This is for backward compatibility with Oracle JSP versions prior to Oracle9iAS release 2, for functionality of include directives. If set to true, page locations in nested include directives are relative to the top-level page. If set to false, page locations are relative to the immediate parent page. This complies with the JSP 1.2 specification.

Note:

For pre-translating pages, the ojspc -oldIncludeFromTop option is equivalent.

precompile_check

(jsp_precompile checking; default: false)

Set this to true to check the HTTP request for a standard jsp_precompile setting. If precompile_check is true and the request enables jsp_precompile, then the JSP page will be pre-translated only, without execution. Setting precompile_check to false improves performance and ignores any jsp_precompile setting in the request.

For more information about jsp_precompile, see "Standard JSP Pre-Translation without Execution", and the Sun Microsystems JavaServer Pages Specification, Version 1.2.

reduce_tag_code

(flag for size reduction of custom tag code; default: false)

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

Note:

For pre-translating pages, the ojspc -reduceTagCode option is equivalent.

req_time_introspection

(flag for request-time introspection; default: false)

A true setting enables request-time JavaBean introspection whenever compile-time introspection is not possible. When compile-time introspection is possible and succeeds, this parameter is ignored and there is no request-time introspection.

As an example of a scenario for use of request-time introspection, assume a tag handler returns a generic java.lang.Object instance in VariableInfo of the tag-extra-info class during translation and compilation, but actually generates more specific objects during request-time (runtime). In this case, if req_time_introspection 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.)

Note:

For pre-translating pages, the ojspc -reqTimeIntrospection option is equivalent.

sqljcmd

(SQLJ translator executable and options; default: null)

This parameter is useful during development in any of the following circumstances:

Specifying a SQLJ translator executable results in its being spawned as a separate process in a separate JVM, instead of within the same JVM as the JSP container.

You can fully specify the path for the executable, or specify only the executable and let the JSP container look for it in the system path.

For example, to run SQLJ with online semantics checking as user scott/tiger, and to generate ISO standard SQLJ code, set sqljcmd to the following value: 

sqljcmd=sqlj -user=scott/tiger -codegen=iso

Appropriate SQLJ libraries must be in the classpath, and any front-end utility (such as sqlj in the example) must be in the system path. For Oracle SQLJ, the translator ZIP or JAR file and the appropriate SQLJ runtime ZIP or JAR file must be in the classpath. See "Key Support Files Provided with OC4J".

Notes:

For pre-translating pages, the ojspc -S option provides related functionality.

static_text_in_chars

(flag to generate static text as characters; default: false)

A true setting directs the JSP translator to generate static text in JSP pages as characters, instead of bytes. 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"); %>

(See "Dynamic Content Type Settings" for related information.)

The false default setting improves performance in outputting static text blocks.

Note:

For pre-translating pages, the ojspc -staticTextInChars option is equivalent.

tags_reuse_default

(setting for tag handler reuse; default: runtime)

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

Note:

For backward compatibility, a setting of true is also supported and is equivalent to runtime, and a setting of false is supported and is equivalent to none.

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

well_known_taglib_loc

(location for shared tag libraries; default: see description)

This specifies a directory where tag library JAR files can be placed for sharing across multiple Web applications. The default value is the following: 

j2ee/home/jsp/lib/taglib/

This is under [Oracle_Home] if [Oracle_Home] is defined. If [Oracle_Home] is not defined, then this default location is under the current directory.

Important:

Additional steps are also required for tag library sharing to work. See "Oracle Extension for Tag Library Sharing".

xml_validate

(XML validation of web.xml file; default: false)

Set this to true to enable XML validation of the application web.xml file. Because the Tomcat reference implementation does not perform XML validation, xml_validate is false by default.

Note:

For pre-translating pages, the ojspc -xmlValidate option is equivalent.

Setting JSP Configuration Parameters in OC4J

In an OC4J standalone development environment, you can set JSP configuration parameters in global-web-application.xml, web.xml, or orion-web.xml, inside the <servlet> element for the JSP front-end servlet. In the portion of global-web-application.xml shown in "JSP Container Setup", the settings would go where the init_params place holder appears. (In an Oracle9iAS production environment, you should use Enterprise Manager for configuration. See "JSP Configuration in Oracle Enterprise Manager".)

The following example lists <servlet> element and subelement settings for the JSP front-end servlet. This sample enables the precompile_check flag, sets the main_mode flag to run without checking timestamps, and runs the Java compiler in verbose mode. 

<servlet>
   <servlet-name>jsp</servlet-name>
   <servlet-class>oracle.jsp.runtimev2.JspServlet</servlet-class>
   <init-param>
      <param-name>precompile_check</param-name>
      <param-value>true</param-value>
   </init-param>
   <init-param>
      <param-name>main_mode</param-name>
      <param-value>justrun</param-value>
   </init-param>
   <init-param>
      <param-name>javaccmd</param-name>
      <param-value>javac -verbose</param-value>
   </init-param>
</servlet>

You can override any settings in the global-web-application.xml file with settings in the web.xml file for a particular application, and you can make deployment-specific overrides of web.xml settings through settings in orion-web.xml. For information about global-web-application.xml and orion-web.xml, see the Oracle9iAS Containers for J2EE Servlet Developer's Guide.

OC4J Configuration Parameters for JSP

There are also OC4J configuration parameters--as opposed to parameters for the JspServlet front-end servlet of the JSP container--which affect JSP pages. This section documents JSP-related attributes of the root <orion-web-app> element of the OC4J global-web-application.xml file or orion-web.xml file. For more information about these files, see the Oracle9iAS Containers for J2EE Servlet Developer's Guide.

JSP-Related OC4J Configuration Parameter Descriptions

The following <orion-web-app> attributes, in the OC4J global-web-application.xml file or orion-web.xml file, affect JSP performance and functionality:

Setting JSP-Related OC4J Configuration Parameters

To set configuration values that would apply to all applications in an OC4J instance, use the <orion-web-app> element of the OC4J global-web-application.xml file. To set configuration values for a particular application deployment, overriding settings in global-web-application.xml, use the <orion-web-app> element of the deployment-specific orion-web.xml file.

Here is an example: 

<orion-web-app ... jsp-print-null="false" ... >
...
</orion-web-app>

Note that the <orion-web-app> element has numerous attributes and subelements. For a complete discussion, see the Oracle9iAS Containers for J2EE Servlet Developer's Guide.

Note:

This discussion assumes an OC4J standalone development environment. In an Oracle9iAS production environment, you generally must use Enterprise Manager for configuration. However, as of Oracle9iAS release 2 (9.0.3), jsp-print-null and jsp-timeout are not yet supported by the Enterprise Manager JSP Properties Page. Given this fact, any settings must be made through the Enterprise Manager Web Module Advanced Properties Page (which enables you to edit orion-web.xml), or directly in the appropriate XML file. In the latter case, you must then run the dcmctl utility, which is a command-line alternative to Enterprise Manager. See "OC4J Deployment Features".

Key OC4J Configuration Files

Be aware of the following key configuration files in the OC4J environment.

Global files for all OC4J applications, in the OC4J configuration files directory:

(In Oracle9iAS, OC4J directory paths are configurable; in OC4J standalone, the configuration files directory is j2ee/home/config by default.)

In addition to the global application.xml file, there is a standard application.xml file, and optionally an orion-application.xml file, for each application. These files are in the application EAR file.

Also, in an application WAR file, which is inside the application EAR file, there is a standard web.xml file and optionally an orion-web.xml file. These are for application-specific and deployment-specific configuration settings, overriding global-web-application.xml settings or providing additional settings as appropriate. The global-web-application.xml and orion-web.xml files support the same elements, which is a superset of those supported by the web.xml file.

If the orion-application.xml and orion-web.xml files are not present in the archive files, they will be generated during initial deployment, according to settings in the global-web-application.xml file.

For additional information, see "Overview of EAR/WAR Deployment". For complete information about the use of these files, see the Oracle9iAS Containers for J2EE User's Guide and the Oracle9iAS Containers for J2EE Servlet Developer's Guide.

JSP Configuration in Oracle Enterprise Manager

In an Oracle9iAS environment, such as for production deployment, you should perform most OC4J configuration through Enterprise Manager. This includes configuration of the front-end JSP servlet for the OC4J JSP container. The following graphic shows the Enterprise Manager JSP Properties Page for an OC4J instance.

(For information beyond what is described here about using Enterprise Manager to configure OC4J, see the Oracle9iAS Containers for J2EE User's Guide. For general information about using Enterprise Manager to manage your Oracle9iAS environment, see the Oracle9i Application Server Administrator's Guide.)

Text description of oemjsp.gif follows.

Text description of the illustration oemjsp.gif

You can drill down to this page as follows:

  1. From the Oracle9iAS Application Server Instance Home Page (the main page you reach when you first access Enterprise Manager), select the name of an OC4J instance in the System Components table. Enterprise Manager displays the OC4J Home Page for the OC4J instance.

  2. From the OC4J Home Page, select JSP Container Properties under Instance Properties in the Administration section of the page.

Configuration Parameters Supported by the JSP Properties Page

Table 3-2 shows the correspondence between JSP container properties shown in the Enterprise Manager JSP Properties Page, and configuration parameters of the JSP container front-end servlet as described in "JSP Configuration Parameters". See that section for the meanings of the settings.

Possible settings are shown with defaults in bold. Note that Enterprise Manager defaults are appropriate for a production environment, so are not necessarily the same as defaults otherwise, which are appropriate for a development environment.

Table 3-2 Enterprise Manager Properties, JSP Configuration Parameters  
Enterprise Manager JSP Container Property Possible Settings JSP Configuration Parameter Possible Settings

Debug Mode

No
Yes

debug_mode

false
true

External Resource for Static Content

No
Yes

external_resource

false
true

Generate Static Text as Bytes

No
Yes

static_text_in_chars

false
true

Tags Reuse Default

No
Yes

tags_reuse_default

none
runtime

Reduce Code Size for Custom Tags

No
Yes

reduce_tag_code

false
true

Emit Debug Info

No
Yes

emit_debuginfo

false
true

When a JSP Changes

Recompile JSP
Reload Classes
Do Nothing

main_mode

recompile
reload
justrun

Precompile Check

No
Yes

precompile_check

false
true

Validate XML

No
Yes

xml_validate

false
true

SQLJ Command

command string (null by default)

sqljcmd

command string (null by default)

Alternate Java Compiler

command string (null by default)

javaccmd

command string (null by default)

Notes:

  • In Oracle9iAS release 2 (9.0.3), Enterprise Manager supports only runtime (not compile-time) tag handler reuse. In other words, tags_reuse_default settings of compiletime or compiletime_with_release are not yet directly supported through Enterprise Manager.

  • The Enterprise Manager JSP container property "Generate Static Text as Bytes" corresponds to the JSP configuration parameter static_text_in_chars, but with opposite orientation. Their defaults are equivalent.

Configuration Parameters Not Supported by the JSP Properties Page

For Enterprise Manager in Oracle9iAS release 2 (9.0.3), the following configuration parameters are not yet supported through the JSP Properties Page:

Instead, you must update them in orion-web.xml or other appropriate XML file (such as web.xml or global-web-application.xml). Edit orion-web.xml or global-web-application.xml through the Enterprise Manager Web Module Advanced Properties Page, as described in the Oracle9iAS Containers for J2EE Servlet Developer's Guide. Also see "Setting JSP Configuration Parameters in OC4J" and "Setting JSP-Related OC4J Configuration Parameters" for related information.

Note:

If you update an XML configuration file manually in Oracle9iAS, you must then run the dcmctl utility, which is a command-line alternative to Enterprise Manager. See "OC4J Deployment Features".

Go to previous page Go to next page
Oracle
Copyright © 2000, 2002 Oracle Corporation.
All Rights Reserved.
Go To Core Documentation
Core		 Go To Platform Documentation
Platform		 Go To Table Of Contents
Contents		 Go To Index
Index