Release 8.1.7
Part Number A83726-01
 Library |
 Product |
 Contents |
 Index |
| Oracle JavaServer Pages Developer's Guide and Reference Release 8.1.7 Part Number A83726-01 |
|
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:
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 |
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.)
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.
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:
.jsp (or .sqljsp) source is not available.
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:
ojspc, you should specify a binary output directory with the ojspc -d option, then archive the directory structure under that specified directory.
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.
Set OracleJSP configuration parameters as follows to execute JSP pages when the .jsp or .sqljsp source is unavailable:
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".
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
For more information, see the Sun Microsystems Java Servlet Specification, Version 2.2.
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:
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. |
|