10g (9.0.4)
Part Number B10322-01
 Home |
 Solution Area |
 Contents |
 Index |
| Oracle Application Server Containers for J2EE User's Guide 10g (9.0.4) Part Number B10322-01 |
|
This chapter describes OC4J and demonstrates how to install OC4J with the Oracle Application Server installation.
This chapter includes the following topics:
Oracle Application Server provides a complete Java 2 Enterprise Edition (J2EE) environment written entirely in Java that executes on the Java virtual machine (JVM) of the standard Java Development Kit (JDK). You can run Oracle Application Server Containers for J2EE (OC4J) on the standard JDK that exists on your operating system. Refer to the certification matrix on http://otn.oracle.com.
OC4J is J2EE certified and provides all the containers, APIs, an services that J2EE specifies. OC4J is based on technology licensed from Ironflare Corporation, which develops the Orion server--one of the leading J2EE containers. Although OC4J is integrated with the Oracle Application Server infrastructure, the product and some of the documentation still contains some reference to the Orion server.
OC4J supports and is certified for the standard J2EE APIs, as listed in Table 1-1.
The OC4J documentation assumes that you have a basic understanding of Java programming, J2EE technology, and Web and EJB application technology. This includes deployment conventions such as the WEB-INF and META-INF directories.
Examples in each of the primers assume the following:
For Web applications, when specifying a URL to execute an application in Oracle Application Server, note that by default in Oracle Application Server, you should use port 7777 to go through the Oracle HTTP Server, with OracleAS Web Cache enabled.
Examples also use standard J2EE configuration files such as web.xml and application.xml.
Among the migration considerations in moving to a Sun Microsystems JDK 1.4 environment, which is the environment that is shipped with Oracle Application Server 10g, there is one of particular importance to servlet and JSP developers.
As stated by Sun Microsystems, "The compiler now rejects import statements that import a type from the unnamed namespace." (This was to address security concerns and ambiguities with previous JDK versions.) Essentially, this means that you cannot invoke a class (a method of a class) that is not within a package. Any attempt to do so will result in a fatal error at compilation time.
This especially affects JSP developers who invoke JavaBeans from their JSP pages, as such beans are often outside of any package (although the JSP 2.0 specification now requires beans to be within packages, in order to satisfy the new compiler requirements). Where JavaBeans outside of packages are invoked, JSP applications that were built and executed in an OC4J 9.0.3 / JDK 1.3.1 environment will no longer work in an OC4J 9.0.4 / JDK 1.4 environment.
Until you update your application so that all JavaBeans and other invoked classes are within packages, you have the alternative of reverting back to a JDK 1.3.1 environment to avoid this issue.
For more information about the "classes not in packages" issue and other JDK 1.4 compatibility issues, refer to the following Web site:
http://java.sun.com/j2se/1.4/compatibility.html
In particular, click the link "Incompatibilities Between Java 2 Platform, Standard Edition, v1.4.0 and v1.3".
Most of the location of J2EE subject matter is obvious. For example, you can find out how to implement and use servlets within the Oracle Application Server Containers for J2EE Servlet Developer's Guide. Table 1-2 shows each J2EE subject matter and where you can find the information in the OC4J documentation set.
OC4J is a lightweight container that is J2EE-compliant. It is configured with powerful and practical defaults and is ready to execute after installation. OC4J is installed with Oracle Application Server; therefore, see the Oracle Application Server 10g Installation Guide for details on OC4J installation.
OC4J is installed within Oracle Application Server with the goal of managing J2EE enterprise systems. Oracle Application Server can manage multiple clustered OC4J processes. Oracle Application Server, which includes OC4J, is managed and configured through the Oracle Enterprise Manager, which can manage and configure your OC4J processes across multiple application server instances and hosts. Thus, you cannot locally manage your OC4J process using the admin.jar tool or by hand editing a single OC4J process' configuration files. This undermines the enterprise management provided by the Oracle Enterprise Manager.
You can still execute OC4J as you have in the past. For those who want a single OC4J instance for development environments or simple business needs, you can download OC4J in standalone mode--complete with documentation.
This following sections discusses both management options in the following sections:
Also, the following section describes how to understand the OC4J documentation set:
You manage Oracle Application Server, including OC4J, using Oracle Enterprise Manager within an enterprise system. This includes clustering, high availability, load balancing, and failover.
You configure each OC4J instance and its properties--within the context of an application server instance--using Oracle Enterprise Manager. After configuration, you start, manage, and control all OC4J instances through Oracle Enterprise Manager. You can group several OC4J processes in a cluster. You must use either the Oracle Enterprise Manager management tool or its command-line tools for starting, stopping, restarting, configuring, and deploying applications.
|
Note:
You cannot use the OC4J standalone tool--
You can modify the XML files locally. If you do so, you must notify Oracle Enterprise Manager that these files have been hand edited through the Distributed Configuration Management (DCM) component tool-- DCM controls and manages configuration for Oracle Application Server instances and its Oracle HTTP Server and OC4J components. For more information on DCM, see the Distributed Configuration Management Reference Guide. |
This book discusses how to start, stop, manage, and configure OC4J in an enterprise environment.
You can still use a single OC4J--outside of the Oracle Application Server environment. After downloading OC4J in oc4j_extended.zip from OTN, you can start, manage, and control all OC4J instances through oc4j.jar and the admin.jar command-line tool. You configure either through the admin.jar command or by modifying the XML files by hand.
Any standalone OC4J process is not managed by Oracle Enterprise Manager and cannot be used within an Oracle Application Server enterprise environment. Typically, you would use standalone for development or for a simple single OC4J instance Web solution.
Download the OC4J Standalone User's Guide for information on how to start, stop, configure, and manage your standalone process.
Aside from this book, the rest of the OC4J documentation set was written with a standalone mindset. These other books may refer to modifying XML files by hand for managing the instance. This book provides a good overview and familiarization of the Oracle Enterprise Manager configuration pages. It also guides you to understand the relationship of each Oracle Enterprise Manager page to its XML counterpart. Use the familiarity of the Oracle Enterprise Manager when reading the other OC4J books. You should be able to look at an XML representation and match it to the relevant Oracle Enterprise Manager field names.
Also, the Distributed Configuration Management (DCM) utility, dcmctl, provides a command-line alternative to using Oracle Enterprise Manager for some management tasks. The dcmctl tool uses the same distributed architecture and synchronization features as Oracle Enterprise Manager, thereby providing identical functionality in a format that is ideal for scripting and automation.
The following functions can be managed through DCM:
For other DCM commands that relate to OC4J, see the Distributed Configuration Management Reference Guide.
For HTTP applications, OC4J is preconfigured to execute behind the Oracle HTTP Server (OHS). You use the Oracle HTTP Server as a front-end listener and OC4J as the back-end J2EE application server.
However, for RMI-based applications--such as EJB and JMS--clients should send their requests directly to OC4J. See "Understanding and Configuring OC4J Listeners" for directions.
For all incoming HTTP communication within the application server environment, you use the OHS as a front-end listener and OC4J as the back-end J2EE application server. Figure 1-1 illustrates this as follows:
The mod_oc4j module is preconfigured to direct all incoming HTTP requests under the j2ee/ Web context to OC4J. This is to separate incoming requests for JServ from those directed to OC4J. Thus, if you want to use the default routing, you can deploy your Web application into a servlet context that includes as its prefix j2ee/. However, any URL mapping you provide in the deployment wizard is automatically added to the mod_oc4j module. See "Configuring Oracle HTTP Server With Another Web Context" for information on what is added to mod_oc4j for you during deployment. For additional information on the mod_oc4j module, see the Oracle HTTP Server Administrator's Guide.
For optimum performance, run OC4J with the JDK that is installed with Oracle Application Server Release 2, which is JDK 1.3.x.
It is not necessary to add anything to your CLASSPATH to run OC4J, because it loads the Java JAR and class files directly from the installation directory, from the lib/ subdirectory, and from the deployed application EAR files.
|
 Copyright © 2002, 2003 Oracle Corporation. All Rights Reserved. |
|
