|
Oracle® Containers for J2EE Deployment Guide
10g Release 3 (10.1.3) Part No. B14431-01 |
|
 Previous |
 Next |
|
Oracle® Containers for J2EE Deployment Guide
10g Release 3 (10.1.3) Part No. B14431-01 |
|
|
Previous |
Next |
This chapter discusses deploying and redeploying Web modules into an OC4J instance. It includes the following topics:
Redeploying an Updated Web Module into an Existing Application
Adding or Modifying JavaServer Pages in an Active Web Module
A standalone Web module packaged as a WAR file can be deployed into an OC4J instance. However, the Web module must be designated a child of either the default application (if a standalone Web application) or another deployed application that does not already contain a Web module component.
Note that a WAR cannot be deployed as the child of an application that already contains a Web module. That is, if the acme application already contains an acme-web.war, an additional WAR file cannot be deployed into that application. Repackage the WAR in the application's EAR file and redeploy the application instead.
OC4J wraps the standalone WAR file within a generated EAR file, then deploys the EAR to the default deployment directory, ORACLE_HOME/j2ee/instance/applications. The EAR includes a generated application.xml deployment descriptor, which includes the context root appended to the URL used to access the Web module.
A restart of OC4J is not required after deployment of a standalone Web module.
In this context, a standalone Web application is a WAR file that has the default application specified as its parent. When a standalone Web application is redeployed, OC4J performs the following:
Removes the Web application from its execution space;
Removes the classloader that was associated with execution of the Web application;
Re-parses the application-specific web.xml and orion-web.xml descriptors to pick up any changes; and
Re-initializes servlet listeners, filters and mappings.
Existing sessions are either purged or serialized out to a file in the persistence directory specified for the Web application, which is defined in the persistence-path attribute of the <orion-web-app> element. When the newly deployed application is started, it looks in the persistence directory for the file containing the serialized sessions.
|
Notes:
|
An updated Web module packaged in a WAR cannot be redeployed into a J2EE application running on OC4J. Instead, the WAR must be re-packaged within the application's EAR file, and the entire EAR must then be redeployed.
OC4J allows new JavaServer Pages (JSPs) to be added to an actively running Web module - as well as existing JSPs to be modified - without requiring an application redeployment or restart.
To use this feature, simply drop a new or updated JSP into the appropriate directory within the exploded WAR file structure in the OC4J instance, which is ORACLE_HOME/j2ee/instance/applications/appName/webModuleName/. OC4J will translate the page and load (or reload) it into the runtime.
This feature is enabled by default, and is managed through the When a JSP Changes JSP configuration parameter. This parameter can be set through the Application Server Control Console user interface as follows:
Click the Administration link ->JSP Properties icon.
Set the When a JSP Changes parameter to one of the following:
Recompile JSPThis is the default setting. OC4J will check the timestamp of the JSP page, retranslate it and reload if it has been modified since it was last loaded. The functionality described below for Reload Classes will also be executed.
Reload ClassesOC4J will check the timestamp of classes generated by the JSP translator, such as page implementation classes, and reload any that have changed or been redeployed since they were last loaded.
This might be useful, for example, when you deploy or redeploy compiled classes, but not JSP pages, from a development environment to a production environment.
Do NothingSet this parameter to disable the auto-reload feature. New or updated JSPs will not be automatically loaded into the OC4J runtime, and the container will not perform any timestamp, any retranslating, of JSP pages or reloading of generated Java classes. This is the most efficient mode for a production environment, where JSP pages are not expected to change frequently.
Restart the OC4J instance for your changes to take effect.
This scenario assumes that any dependent classes already exist within the deployed Web module, and that the JSP updates do not require any changes to the web.xml or orion-web.xml configuration files. If either of these conditions is false, the Web module must be re-packaged as a WAR file and redeployed with the full application within an EAR file.
In an OC4J standalone environment, you can allow new JSPs to be added to a running Web module by setting the main_mode <init-param> element directly in the global-web-application.xml file, which is the configuration file for the OC4J servlet and JSP containers. The values set through Application Server Control Console are persisted to this file.
Valid settings for main_mode are:
reload: Maps to the Reload Classes parameter set through the Application Server Control Console user interface.
recompile (default): Maps to the Recompile JSP parameter.
justrun: Maps to the Do Nothing parameter.
The following example illustrates how to set the main_mode <init-param> element to recompile, which forces OC4J to check the timestamp of the JSP page, retranslate it, and reload it if it has been modified since it was last loaded.
<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>recompile</param-value>
</init-param>
<init-param>
<param-name>javaccmd</param-name>
<param-value>javac -verbose</param-value>
</init-param>
</servlet>
