Oracle JavaServer Pages Developer's Guide and Reference Release 8.1.7 Part Number A83726-01 |
Library | Service | Contents | Index

## Additional JSP Deployment Considerations

Most of this chapter focuses on translation and deployment when targeting the Oracle Servlet Engine, because running in the database is a special situation requiring special considerations and logistics.

This section covers a variety of additional deployment considerations and scenarios, mostly for situations where you are not targeting the Oracle Servlet Engine.

The following topics are covered:

- Doc Root for Oracle Internet Application Server Versus Oracle Servlet Engine

- Use of ojspc for Pre-Translation for Non-OSE Environments

- General JSP Pre-Translation Without Execution

- Deployment of Binary Files Only

- WAR Deployment

- Deployment of JSP Pages with JDeveloper

### Doc Root for Oracle Internet Application Server Versus Oracle Servlet Engine

Both the Oracle Servlet Engine and the Oracle Internet Application Server use the Oracle HTTP Server, essentially an Apache environment, as the Web server for HTTP requests. However, each environment uses its own doc root.

JSP pages and servlets running in the Oracle Servlet Engine, which are routed through the Apache `mod_ose` module provided by Oracle, use the OSE doc root of the relevant servlet context. OSE doc root directories are in the file system, but are linked to the Oracle8i JNDI mechanism.

Remember that for JSP pages running in OSE, only static files are located in or under the doc root. JSP pages are in the database.

The OSE doc root directory is either the default doc root--`$ORACLE_HOME/jis/public_html`--or a doc root specified using the session shell `createcontext` command `-docroot` option when the servlet context was created.

JSP pages and servlets running in the Apache/JServ environment of the Oracle Internet Application Server (release 1.0.x), which are routed through the Apache `mod_jserv` module provided with JServ, use the Apache doc root. This doc root (typically `htdocs`) is set in the `DocumentRoot` command of the Apache `httpd.conf` configuration file.

For JSP pages running in JServ, JSP pages as well as static files are located in or under the doc root.

If you are migrating between the Apache/JServ environment and the OSE environment, move or copy static files to the appropriate doc root.

Note: For an overview of the role of the Oracle HTTP Server and its `mod_ose` and `mod_jserv` modules, see "Role of the Oracle HTTP Server, Powered by Apache".

### Use of ojspc for Pre-Translation for Non-OSE Environments

The Oracle `ojspc` tool, described in detail in "The ojspc Pre-Translation Tool", is typically used for client-side JSP translation for deployment to Oracle8i. However, you can use `ojspc` to pre-translate JSP pages in any environment, which may be useful in saving end-users the translation overhead the first time a page is executed.

If you are pre-translating in some other target environment, specify the `ojspc -d` option to set an appropriate base directory for placement of generated binary files.

As an example, consider an Apache/JServ environment with the following JSP source file:

    htdocs/test/foo.jsp

A user would invoke this with the following URL:

    http://host[:port]/test/foo.jsp

During on-demand translation at execution time, the OracleJSP translator would use a base directory of `htdocs/_pages` for placement of generated binary files. Therefore, if you pre-translate, you should set `htdocs/_pages` as the base directory for binary output, such as in the following example (assume `%` is a UNIX prompt):

    % cd htdocs
    % ojspc -d _pages test/foo.jsp

The URL noted above specifies an application-relative path of `test/foo.jsp`, so at execution time the OracleJSP container looks for the binary files in a `test` subdirectory under the `htdocs/_pages` directory. This subdirectory would be created automatically by `ojspc` if it is run as in the above example. At execution time, the OracleJSP container would find the pre-translated binaries and would not have to perform translation, assuming that the source file was not altered after pre-translation. (By default, the page would be re-translated if the source file timestamp is later than the binary timestamp, assuming the source file is available and the `bypass_source` configuration parameter is not enabled.)

### General JSP Pre-Translation Without Execution

In an on-demand translation environment, it is possible to specify JSP pre-translation only, without execution, by enabling the `jsp_precompile` request parameter when invoking the JSP page from the end-user's browser.

Following is an example:

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

Refer to the Sun Microsystems JavaServer Pages Specification, Version 1.1, for more information.

### Deployment of Binary Files Only

If your JSP source is proprietary, you can avoid exposing the source by pre-translating JSP pages and deploying only the translated and compiled binary files. Pages that are pre-translated, either from previous execution in an on-demand translation scenario or by using `ojspc`, can be deployed to any environment that supports the OracleJSP container. There are two aspects to this scenario:

- You must deploy the binary files appropriately.

- In the target environment, OracleJSP must be configured properly to run pages when the `.jsp` (or `.sqljsp`) source is not available.

#### Deploying the Binary Files

After JSP pages have been translated, archive the directory structure and contents that are under the binary output directory, then copy the directory structure and contents to the target environment, as appropriate. For example:

- If you pre-translate with `ojspc`, you should specify a binary output directory with the `ojspc -d` option, then archive the directory structure under that specified directory.

- If you are archiving binary files produced during previous execution in an Apache/JServ (on-demand translation) environment, archive the output directory structure, typically under the `htdocs/_pages` directory.

In the target environment, restore the archived directory structure under the appropriate directory, such as under the `htdocs/_pages` directory in an Apache/JServ environment.

#### Configuring OracleJSP for Execution with Binary Files Only

Set OracleJSP configuration parameters as follows to execute JSP pages when the `.jsp` or `.sqljsp` source is unavailable:

- `bypass_source=true`

- `developer_mode=false`

Without these settings, OracleJSP will always look for the `.jsp` or `.sqljsp` file to see if it has been modified more recently than the page implementation `.class` file, and abort with a "file not found" error if it cannot find the `.jsp` or `.sqljsp` file.

With these parameters set appropriately, the end-user can invoke a page with the same URL that would be used if the source file were in place. For an example, consider an Apache/JServ environment--if the binary files for `foo.jsp` are in the `htdocs/_pages/test` directory, then the page can be invoked with the following URL without `foo.jsp` being present:

    http://host:[port]/test/foo.jsp

For how to set configuration parameters, see "OracleJSP Configuration Parameter Settings".

### WAR Deployment

The Sun Microsystems JavaServer Pages Specification, Version 1.1 supports the packaging and deployment of Web applications, including JavaServer Pages, according to the Sun Microsystems Java Servlet Specification, Version 2.2.

In typical JSP 1.1 implementations, JSP pages are deployed through the WAR (Web archive) mechanism. WAR files are created using 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 2.2 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 2.2 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 intended.

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

To summarize, the WAR file includes the following:

- `web.xml` deployment descriptor

- JSP pages

- required JavaBeans and other support classes

- required static HTML files

For more information, see the Sun Microsystems Java Servlet Specification, Version 2.2.

Note: The OracleJSP WAR file implementation and further documentation will be available through the Oracle Technology Network shortly after the Oracle8i 8.1.7 release. In release 8.1.7, OracleJSP uses `web.xml` in only a limited way, for JSP tag library descriptors and servlet URL shortcuts.

### Deployment of JSP Pages with JDeveloper

Oracle JDeveloper release 3.1 includes a deployment option, "Web Application to Web Server", that was added specifically for JSP applications.

This option generates a deployment profile that specifies the following:

- a JAR file containing Business Components for Java (BC4J) classes required by the JSP application

- static HTML files required by the JSP application

- the path to the Web server

The developer can either deploy the application immediately upon creating the profile or save the profile for later use.

| Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
Library | Service | Contents | Index