Running Oracle JSP on Apache

Oracle JSP is implemented as a servlet. It can run in Apache JServ 1.0. To run in the Apache environment you must install both an Apache server and the corresponding Apache JServ. Oracle JSP is then installed/configured as another servlet in the environment.

  1. Download/install the latest Apache server. (Currently 1.3.9).
     
  2. If not already installed, download/install JDK 1.1 or JDK 1.2. JDK 1.2 is recommended as the next release of Oracle JSP (1.0.0.4.0) will require configuring with a Java 1.2 compiler (I.e. a compiler that supports the -encoding flag).
     
  3. Download/install the Java Servlet 2.0 Development kit.
    Apache requires but doesn't include the 2.0 JSDK
     
  4. Download/install the JavaServer 1.0 Web Development kit.
    The JSWDK contains the required JSP interfaces.
     
  5. Download/install the latest Apache JServ. (CurrentlyApache JServ 1.0).
     
  6. Download Oracle JSP and samples from this website.
     
  7. Install/configure ojsp.jar.


    Follow these steps:

    1. Copy ojsp.jar into the root Apache servlet zone you want to run your generated pages from.

    2. Configure Apache JServ to map *.jsp to JspServlet (mod_jserv.conf). See here for example. Note: Earlier versions of Apache included the content of mod_jserv.conf at the end of Apache's main configuration file httpd.conf.  If you are running on one of these older versions then make this modification in httpd.conf.

    a) Mount the zone:
    Ex: ApjServMount /servlets /root

    b) Map the .jsp extension to the JspServlet.
    Ex: ApJServAction .jsp /servlets/oracle.jsp.JspServlet

    3. Configure the Apache JServlet properties (jserv.properties). See here for an example.
    a) Add ojsp.jar to the classpath.
    b) Add servlet.jar (from JSWDK-1.0) to the classpath.
    Note: this line must be after the line that adds the jskd.jar to the classpath
    c) If you are using JDK 1.2 add the tools.jar from your JDKs lib directory to the classpath
    d) Optionally, add xmlparsev2.jar to the classpath. (This is required if you want to run the helloxml sample).
    e) If you want to enable SQLJ, add translator.zip to the classpath. Additionally, download and add a JDBC driver to your classpath.
     

    4. If you want to overide the JSP default behavior, configure it by setting the appropriate initArgs values in your JServlet zone properties. See here for an example.

  8. Install the samples.


    The samples are contained in the webroot directory. They should be copied somewhere beneath the webservers document root directory. In a typical Apache installation this is htdocs.
     
     

  9. Run the server and point your browser to the index.html page in the installed samples directory.
     


Configuring the JspServlet.

The JspServlet requires no configuration/settings to run. However, its behavior can be tailored by setting the following initArgs in the Jserv zone's properties file that hosts the JspServlet.

Common setting:

developer_mode: This flag controls the runtime behavior of the JSP engine. The values are true or false. The default is true. If set to true the JSP engine will check whether to retranslate/reload the requested page/application on every request.  If set to false the JSP engine will only check whether to translate when the initial request for the page/application is received. It is recommended that deployment environments set developer_mode to false to maximize performance. For example:

servlet.oracle.jsp.JspServlet.initArgs=developer_mode=false

translate_params: This flag let's you override servlet engines that don't encode mulitbyte (NLS) request (form) parameters. The values are true or false. The default is false. If set to true the JSP engine will encode the request parameters itself. If false, the JSP engine will return the parameters from the servlet engine unchanged. When developing multibyte JSPs, it is important you determine if the servlet environment you are running in supports multibyte request parameters or not.  Setting translate_params to true in an environment that correctly handles parameter encoding will yield incorrect results. For example:

servlet.oracle.jsp.JspServlet.initArgs=translate_params=true

page_repository_root: By default, the JspServlet uses the Apache servers document repository to generate/load translated JSPs. The generated .java/.class files are written into a special directory called _pages in the root directory of the application this page is contained in. If the page is not contained in an application it is written into the _pages subdirectory in the server's docroot directory. If you want a the JspServlet to generate pages to a location outside the server's docroot set the page_repository_root initArg. The value of this argument should be a fully qualifed path to the root directory into which pages will be generated/run. This directory need not exist. For example:

servlet.oracle.jsp.JspServlet.initArgs=page_repository_root=c:\jsps

classpath: By default, the JspServlet loads classes from either the system classpath or the page repository. If additional class dependencies exist they can be specified using the classpath initArgs. The form for specifying a classpath follows the conventions that the platform uses for specifying a regular Java classpath. For example:

servlet.oracle.jsp.JspServlet.initArgs=classpath=c:\somedir\myapp.jar

It is currently recommended that all dependent classes be included in the regular JServ classpath rather than via this setting as this version is still working through some class loader issues.

Uncommon settings:

page_provider_root: By default, the JspServlet uses the web servers document repository to locate the .jsp file that corresponds to the incoming request. page_provider_root let's the JspServlet pull these files from an alternative repository/location. It is primarily provided to support server's that don't use the filesystem as their repository. It is not recommended that users set this initArgs when running on Apache.

page_provider: By default the JspServlet assumes pages are being delivered from/to a filesystem. This is not universally true for all Oracle implementations. This setting let's you specify an alternative class to be used as a page provider for the JspServlet. Currently there are no alternatives implemented.

page_repository: By default the JspServlet assumes generated pages are being delivered from/to a filesystem. This is not universally true for all Oracle implementations. This setting let's you specify an alternative class to be used manage a page repository for the JspServlet. Currently there are no alternatives implemented.

classloader: By default the JspServlet assumes classes are being loaded from a filesystem. This is not universally true for all Oracle implementations. This setting let's you specify an alternative class to be used implement a classloader for the JspServlet. Currently there are no alternatives implemented.

jspcompiler: By default the JspServlet uses the builtin Java compiler (javac). Pages are read directly from the filesystem. In the future we plan to supprot in memory compilation as well as compiling out of different repository types. This setting names the class that implements the JspCompiler interface. Currently there are no alternatives implemented.