 |
|
Java Server Pages (JSPs) and OC4J
Oracle Application Server Tips by Burleson
Consulting |
Java Server Pages are another web component
handled by mod_oc4j. JSPs are HTTP pages that contain Java code or
calls to servlets or both. JSPs are passed to the JSP container for
processing. JSP code is compiled into class files for execution like
a servlet. In fact, the JSP container is itself a servlet running in
the servlet container. The JSP container complies with the JSP 1.2
specification. A JSP can contain anything an HTTP page can contain.
<HTML>
<HEAD><TITLE>John?s Neat Web
Site</TITLE></HEAD>
<BODY>
<H3>H1 Welcome to my web site!!!</H3>
<P>Current time on my server is <%= new
java.util.Date() %>.</P>
</BODY>
</HTML>
This small JSP appears to be mostly standard
HTTP tags, and it is. The only Java on the page is defined by the
<% %> brackets?in this case a call to the Java Date class that
returns the current server date. This is a simple example of
embedding Java code directly into a JSP.
JSPs are typically used in the
application presentation layer and are an effective way to separate
the presentation code from the application code. However, JSPs are
powerful enough to contain a lot of the application code, thereby
violating this separation of layers. Oracle has provided an
extensive array of added JSP features that include custom tag
libraries, monitoring capabilities, and caching technology. Again, a
discussion of developing and coding Java Server Pages is beyond the
scope of this book, so we will focus on managing and administering
JSPs in the Oracle Application Server. Development of JSPs is
covered extensively in the references named at the beginning of this
chapter.
Normally, the JSP container runs Java
Server Pages on demand. When OHS receives a request for a JSP, it
passes the request to the JSP servlet that finds the file,
translates and compiles it (if necessary), and executes it,
resulting in the JSP being served to the client. If the JSP servlet
finds a compiled version with a timestamp after the source version,
it will execute the compiled version without recompiling. There are
cases where you will want to precompile your JSPs. The most common
is deploying an application when you do not want to include the
source files. In this case Oracle provides a tool called ojspc that
compiles the JSPs into the appropriate directories. The ojspc
program, located in $ORACLE_HOME/bin, takes a JSP file (ending in .jsp)
and normally produces two class files, one for the page and the
other containing the Java code. There are a number of limits on the
use of ojspc to precompile JSPs, so you will need to refer to the
documentation before using it.
The JSP container is preconfigured
when installed. The global-web-application.xml file defines the
files that are mapped to the JSP container for serving and contains
the Jspservlet configuration parameters.
<servlet>
<servlet-name>jsp</servlet-name>
<servletclass>oracle.jsp.runtimev2.JspServlet</servlet-class>
<load-on-startup>0</load-on-startup>
<init-param>
<param-name>check_page_scope</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>main_mode</param-name>
<param-value>justrun</param-value>
</init-param>
The preceding code snippet from the
global-web-application.xml file defines the Servlet used to execute
JSP pages as oracle.jsp.runtimev2.JspServlet. It then sets a
parameter called main_mode with a parameter value of justrun. A
number of parameters can be used to configure the JSP servlet. To
use the default parameter settings, simply do not define the
parameter in the file. The following are the parameters specific to
the JSP servlet:
<init-param>
<param-name>debug_mode</param-name>
<param-value>true</param-value>
</init-param>
The debug_mode parameter defaults to
true and will cause a stack trace to be printed for a run-time
exception.
<init-param>
<param-name>emit_debuginfo</param-name>
<param-value>false</param-value>
</init-param>
The emit_debuginfo parameter defaults
to false. In the default mode an error will generate a map to the
.java files. If true, it will generate a map to the .jsp file. Set
this parameter to true during development to enable JSP debugging.
<init-param>
<param-name>external_resource</param-name>
<param-value>false</param-value>
</init-param>
The external_resource parameter
defaults to false. If set to true, static page content is placed in
a separate resource file during translation. This will speed
translation and may speed execution of JSPs with a large amount of
static content.
<init-param>
<param-name>javaccmd</param-name>
<param-value>javac -verbose</param-value>
</init-param>
The javaccmd parameter can be used to
specify command-line compile options, a different compiler, or both.
By specifying a Java compiler to use, you will cause the compiler to
execute in a separate JVM. The new compiler must be in the CLASSPATH.
The preceding example uses the default compiler but forces it to
execute in a separate JVM with the verbose argument added to the
command line.
<init-param>
<param-name>main_mode</param-name>
<param-value>recompile</param-value>
</init-param>
The main_mode parameters tell the JSP
container whether to use automatic recompilation. The default is
recompile, which will cause the JSP servlet to check the timestamp
on the .jsp file to determine whether it must automatically
retranslate and recompile it before executing. This will also cause
it to check any other resource used by the JSP, including JavaBeans,
and recompile them if needed. The reload option will verify all
required class files and recompile as needed. The justrun option
will run the compiled code without checking the source.
During development it is recommended
that you maintain the default setting. However, once your
application is deployed and source files no longer change, it is
more efficient to change to the justrun option.
<init-param>
<param-name>old_include_from_top</param-name>
<param-value>false</param-value>
</init-param>
The old_include_from_top parameter is
used for compatibility with pre-Oracle9iAS Release 2 versions. It
defaults to false where page locations relate to the parent page.
Setting it to true will cause page locations in nested includes to
relate to the top-level page.
<init-param>
<param-name>precompile_check</param-name>
<param-value>false</param-value>
</init-param>
The precompile_check parameter
defaults to false, which causes the JSP servlet to ignore the HTTP
jsp_precompile parameter. Setting it to true will cause the servlet
to check the jsp_precompile setting and if present, translate and
compile the JSP without executing it.
<init-param>
<param-name>reduce_tag_code</param-name>
<param-value>false</param-value>
</init-param>
The reduce_tag_code parameter defaults
to false. If set to true, the JSP servlet will produce smaller code
for custom tags; however, tag reuse (pooling) may be reduced,
affecting performance.
<init-param>
<param-name>req_time_introspect</param-name>
<param-value>false</param-value>
</init-param>
The req_time_introspect parameter
defaults to false. When set to true, the JSP container will perform
JavaBean introspection at run time if it was unable to at compile
time. JavaBean introspection is the process of examining a bean to
determine which properties, methods, and events it supports. In some
cases, a compile-time introspection will not be able to determine
this information, and therefore it may be necessary to conduct
introspection at run time.
<init-param>
<param-name>sqljcmd</param-name>
<param-value>sqlj ?user=scott/tiger</param-value>
</init-param>
Like the javaccmd parameter, the
sqljcmd command can identify a different sqlj processor to use, set
command-line options, or both. It defaults to null. If it is set,
the sqlj processor will run in a separate JVM, and all necessary
libraries must be in the CLASSPATH.
<init-param>
<param-name>static_text_in_chars</param-name>
<param-value>false</param-value>
</init-param>
The static_text_in_chars parameter
defaults to false. This parameter must be set to true if you need to
change the character encoding at run time. Setting the parameter to
true will reduce performance.
<init-param>
<param-name>tags_reuse_default</param-name>
<param-value>true</param-value>
</init-param>
The parameter defaults to true and
establishes a default setting for tag reuse. Each page can contain
this parameter and will change the behavior for only that page. An
example of a JSP page setting the tag reuse behavior for that page
is shown here:
pageContext.setAttribute("oracle.jsp.tags.reuse", new Boolean(false));
The preceding parameter will change
the default behavior for that JSP to false.
<init-param>
<param-name>xml_validate</param-name>
<param-value>false</param-value>
</init-param>
The xml_validate parameter specifies whether the web.xml file
and the tag library description files are validated before use. The
default is false.
Apache Jserv
Apache?s Jserv module (mod_jserv) is
still shipped with Oracle Application Server 10g, even though it is
not the default method for supporting Java servlets. Before Apache
had access to an application server, it needed a method to reliably
and efficiently execute servlets. Since adding a Java Virtual
Machine to the Apache code was prohibitive, mod_jserv was created to
pass servlets to an external servlet engine called Jserv. Once
loaded, mod_jserv was passed all servlet requests, which it then
passed to Jserv. The communication between the two programs used the
AJP (Apache Jserv Protocol), which is the same protocol used by
mod_oc4j. Mod_jserv was also responsible for starting, stopping, and
monitoring Jserv.
To install mod_jserv, uncomment the
line in the OHS configuration file http.conf.
# Include the configuration files needed for
jserv
include "/home/oracle/oraportal904/Apache/Jserv/etc/jserv.conf"
A look in the $ORACLE_HOME/Apache/Jserv/etc/
directory will display the Jserv configuration files.
jserv.conf
jserv.properties
zone.properties
Jserv.conf loads the mod_jserv module
and configures the AJP version used for communication. At the end is
a location directive that when uncommented, will allow you to check
Jserv?s status from the identified URL. The jserv.properties file is
the main configuration file for the servlet engine. Zone.properties
identifies file repositories from which classes are loaded. Because
mod_jserv has been deprecated, we are not going to go any deeper
into its configuration. If you need additional information, refer to
the Oracle HTTP Server Administration Guide. Oracle Application
Server 10g can also be configured to use mod_jserv and mod-oc4j
together. You need to designate which programs run under which
engine. Although it is possible to use these two programs together,
it is recommended that you use mod_oc4j unless there is a compelling
reason to activate mod_jserv. Also note that with the release of the
Apache 2.0 web server, Tomcat is the preferred servlet engine and
mod_jserv is no longer supported.
Note: You will still find OHS using Jserv
with the Oracle database because it does not ship with the OC4J
container.
This is an excerpt from "Oracle
10g Application Server Administration Handbook" by Don Burleson
and John Garmany.
and include the URL for the page.
