Oracle Containers for J2EE (OC4J)
Pages: 1, 2
J2EE Application Deployment
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.
Automatic Finder Methods Generation
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="18.104.22.168" 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
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:
- Server-level logging; normally contains server startup, shutdown, and internal server errors.
- Application-level logging for each of the deployed applications; contains all events related to an application.
- Web access log
- Contains all Web access information.
- RMI log
- Logs RMI events and errors.
- JMS log
- Logs JMS events and errors.
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.