| Oracle® Containers for J2EE Deployment Guide 10g (10.1.3.1.0) Part Number B28951-01 |
|
|
View PDF |
| Oracle® Containers for J2EE Deployment Guide 10g (10.1.3.1.0) Part Number B28951-01 |
|
|
View PDF |
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.
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 class loader that was associated with execution of the Web application
Reparses the application-specific web.xml and orion-web.xml descriptors to pick up any changes
Reinitializes 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 repackaged within the application's EAR file, and the entire EAR must then be redeployed.
In OC4J, you can add new JavaServer Pages (JSPs) to an actively running Web module and modify existing JSPs without 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, as follows:
Click the Administration tab for an OC4J instance.
Select JSP Properties.
Set the When a JSP Changes parameter to one of the following values:
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 in the following description 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 any reloading of generated Java classes. This is the most efficient mode for a production environment, in which 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 file. If either of these conditions is false, the Web module must be repackaged as a WAR file and redeployed with the full application within an EAR file.
In an OC4J standalone environment, you can configure adding new JSPs 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.
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>
|
Note: Thejavaccmd parameter is deprecated in OC4J (10.1.3.1.0). |
