With the release of version 184.108.40.206 of its 9i Application Server, Oracle introduced a fast, scalable, developer-friendly J2EE container. OC4J, as it is popularly known, was licensed from Ironflare, makers of the Orion server, and was enhanced by Oracle and integrated with other components in the application server stack.
A future article will discuss the just-released developers' preview version of OC4J 2.0. 9iAS release 2 includes complete support for Enterprise JavaBeans (EJB) 2.0, Servlets 2.3, JavaServer Pages (JSP) 1.2, JTA 1.0, JNDI 1.2, JMS 1.0, JDBC 2.0, JavaMail 1.2, JAF 1.0, JAXP 1.1, Connector 1.0, and JAAS 1.0. OC4J also supports standard services such as JSP Tag libraries, and provides advanced clustering facilities to support both stateless and stateful application failover of servlets and EJBs. This article only discusses the features provided in the 220.127.116.11.x version of 9iAS Oc4J.
OC4J 18.104.22.168 is a J2EE-1.2-certified application server. OC4J provides the performance, scalability, and features (like HTTP clustering and load balancing) necessary for deployment as an enterprise application server. In addition, it boasts several features to make developers' lives easier during the development phase. In this article, I will cover the ease-of-use and developer features that make OC4J an attractive option for developing and deploying J2EE applications.
OC4J can either be installed from 9iAS software distribution or downloaded from the Oracle Technology management Web site. OC4J is developed purely in Java and hence the same distribution works for most of its platforms (Windows, Linux, Solaris, HP).
The installation of the J2EE container is very simple and takes only few minutes. You need JDK 1.2.2 or higher installed on your machine and java binaries included in your path. If the
unzip utility is not available in your environment, you can use the
jar utility to install the server from the
Following are the steps involved in installing OC4J:
$ cd ias $ unzip oc4j.zip (or jar xvf oc4j.zip) $ cd j2ee/home $ java -jar orion.jar -install Enter an admin password to use: debu Confirm admin password: debu Installation done
The application server configuration files consists of seven XML files residing in the
$IAS_HOME/j2ee/home/config directory; the names of the XML files are self-explanatory.
The following list provides a brief description about the configuration files.
By default, OC4J has a Web server configured to listen for HTTP requests at port 8888; you can change the port by editing
The OC4J server can be started with a single command and the process runs in a single JVM. After the OC4J server is started, you can invoke your Web site as
http://<servername>:8888. The command to start and shutdown OC4J is:
$ java -jar orion.jar Oracle9iAS (22.214.171.124.1) Containers for J2EE initialized $ java -jar admin.jar ormi://localhost admin debu -shutdown $
OC4J provides J2EE-standard EAR and WAR file deployment. The greatest benefit of OC4J is that you can deploy J2EE-compliant EAR as is, with no changes or repackaging required. Just point to the location of the EAR file, and OC4J will automatically deploy the application to the application server. The deployment process is quite developer-friendly, as it automatically deploys the EJB-JARs and WARs included in the EAR file. The EJB deployment process automatically generates the stubs; for CMP beans, it generates the finder methods.
OC4J is certified with Oracle8i and 9i databases out of the box and comes with Oracle's Type 4 JDBC driver. OC4J is also certified with Merant JDBC Drivers for connecting to non-Oracle databases (SQLServer, DB2, etc). DataSources can be configured using
data-sources.xml. Following is a typical example of a DataSource:
<data-sources> <!-- An example/default DataSource that uses Oracle JDBC-driver to create the connections. This tag creates all the needed kinds of data-sources, transactional, pooled and EJB-aware sources. The source generally used in application code is the "EJB" one - it provides transactional safety and connection pooling. Oracle thin driver could be used as well, like below. url="jdbc:oracle:thin:@host:port:sid" --> <data-source class="com.evermind.sql.DriverManagerDataSource" name="OracleDS" location="jdbc/OracleCoreDS" xa-location="jdbc/xa/OracleXADS" ejb-location="jdbc/OracleDS" connection-driver="oracle.jdbc.driver.OracleDriver" username="scott" password="tiger" url="jdbc:oracle:thin:@localhost:1521:DEBU" inactivity-timeout="30" /> </data-sources>
You can deploy a J2EE application, i.e., an EAR file, either by making an entry in the
server.xml file for the application or by using command-line options. For example, we have our application packaged as
timecard.ear and it has an EJB called
work-ejb.jar and WAR called
work.war. We deploy the the application as follows:
C:\oracle\iSuites\j2ee\home> java -jar admin.jar ormi://localhost admin debu -deploy -deploymentName TimeCardApp -file c:\time\ear\timecard.ear Auto-unpacking C:\oracle\iSuites\j2ee\home\applications\timecard.ear... done. Auto-unpacking C:\oracle\iSuites\j2ee\home\applications\timecard\work.war... done. Auto-deploying TimeCardApp (New server version detected)... Auto-deploying work-ejb.jar (No previous deployment found)... Auto-creating table: create table work_ejb_WorkHours (email VARCHAR2(255) not null, monthEnding DATE not null, workHours double precision null, trainingHours double precision null, vacationHours double precision null, otherHours double precision null, primary key (email, monthEnding)) done.
The EJB deployment process will automatically generate the stubs and automatically create the table for the CMP entity bean if the table does not exist in the database.
As the timecard application has a WAR module called
work.war the context URI for the Web module can be set by either modifying
default-web-site.xml or as in the following command:
C:\oracle\iSuites\j2ee\home>java -jar admin.jar ormi://localhost admin debu -bindWebApp TimeCardApp work default-web-site /time
Now we would be able to access the Web module by accessing
OC4J does not explicitly require an EAR or WAR file, and it supports an open extended directory structure similar to the directory structure in an EAR or WAR file. You can specify the parent directory of the open extended directory to be the location of your application. This is very helpful during the development phase of a project, and you don't always have to build the EAR/WAR file for every code change. Whenever there is a change in a servlet class or JSP, you can just change the time stamp of
web.xml (by the Unix
touch command or some other method) for the Web application, and the Oc4J server will flagged about the code change. It will re-deploy the application, so you don't have to bounce your server for every code change.
OC4J automatically generates finder methods for CMP beans. For simple finder methods, you don't have to do anything; these are automatically generated during deployment. For example, say you have a finder method called
findByemail where email is one of the cmp-fields in your entity bean. If you have a complex finder method, however, you need a finder method to be documented in the vendor-specific deployment descriptor, i.e.,
orion-ejb-jar.xml as follows. This is for a finder method called
findExpensiveEmployees, which finds all employees making a salary above a certain amount.
<finder-method query="$salary > ; $1"> <method> <ejb-name>work.ejb.WorkHours</ejb-name> <method-name>findExpensiveEmployees</method-name> <method-params> <method-param>double</method-param> </method-params> </method> </finder-method>
The easiest thing to do is to deploy the EJB once, get
orion-ejb-jar.xml generated in the application
-deployments directory, make modifications in this file per your requirements, and then package this in your
The most promising feature for developers is that OC4J can automatically detect code changes and automatically compile them for you. In order to achieve this functionality, you have to specify the "development=true" attribute in the
global-web-application.xml file for all deployed applications, or
orion-web-application.xml for a particular application. Also, you can set
source-directory to tell the OC4J server where to look for sources for servlet classes for auto-compiling. By default, Oc4J server will use the
WEB-INF/src directory if it exists; otherwise, it will use the
<?xml version="1.0"?> <!DOCTYPE orion-web-app PUBLIC "-//Evermind//DTD Orion Web Application 2.3//EN" "http://xmlns.oracle.com/ias/dtds/orion-web.dtd"> <orion-web-app deployment-version="126.96.36.199" jsp-cache-directory="./persistence" temporary-directory="./temp" servlet-webdir="/servlet/" development="true" > </orion-web-app>
When this configuration is set, you can also look at the intermediate Java code for a JSP. The generated servlet code will be saved in the persistence directory for your application. The persistence directory can be found in the
$ORACLE_J2EE_HOME/application-deployments/application directory, where
application is the name of the application you are using.
Logging and debugging are very crucial for an application during its life cycle. Oc4J provides several facilities for logging of activities in the server and features to help debug problems encountered in an application.
Oc4J provides the following types of logging:
Generally, developers put a lot of
System.out.println statements in their code to perform application debugging. Normally, all standard outputs and error outputs are routed to the console where the OC4J server is started. If you want to capture the standard output and error outputs to files for logging/debugging purposes, then you can use the
-err options while starting up the Oc4J server to specify which files to use.
Some issues are difficult to track down; sometimes you might need to debug at different sub-system levels in the application server. OC4J provides a number of system properties and you can use these in the comand line while starting to enable this system-level debugging. For example, if you want to enable HTTP session-level debugging, start the OC4J server as follows:
java -Dhttp.session.debug=true -jar orion.jar
Debu Panda is a Senior Principal Product Manager of the Oracle Application Server development team.
Return to ONJava.com.
Copyright © 2009 O'Reilly Media, Inc.