| ||
To new users, OC4J can seem much quieter than other application servers. This is because, by default, it doesn't log routine events to the console (though your application may be generating plenty of noise there with its own debug statements).
Instead, OC4J logs different types of events to different files in the j2ee/home/log directory . Table 4-4 gives the (default) name and description of each log file, along with the configuration file that lets you change its name and location.
Log File | Description |
---|---|
global-application.log | Logs all global application events and errors. This is the application log for the global application and is configured in j2ee/home/config/application.xml . |
jms.log | Logs all JMS- related events and errors. The name/location of this file can be changed in jms.xml . |
rmi.log | Logs all RMI-related events and errors. The name/location of this file can be changed in rmi.xml . |
server.log | All events and errors not logged in other log files (for example, server startup, server shutdown, internal errors, other events and errors not related to applications, websites , JMS, or RMI). The name/location of this file can be changed in server.xml . |
application.log | Logs all events and errors related to a single deployed application. The name/location of this file can be changed inside the application's orion-application.xml descriptor (see Chapter 9). |
http-web-access.log | Logs all web access for a particular website. Each website can configure its own separate access log in its j2ee/home/config/*-web-site.xml configuration file. |
Each log file can be renamed and moved by editing the appropriate configuration file (listed in Table 4-4).
For example, the name and location of the web-access log for a website can be configured in its *-web-site.xml like this:
<web-site port="7001" display-name="Acme Web Site" > ... <access-log path="../log/web-store.log" /> ... </web-site>
All other log files are configured like this:
<root-element-of-the-appropriate-configuration-file> ... <log><file path="../log/somefilename.log" /></log> ... </root-element-of-the- appropriate-configuration-file>
Relative file paths always start from the same directory as the server.xml configuration file (which defaults to j2ee/home/config ). However, it can also be useful to specify absolute paths if you want to write logs to a special partition or give log access to developers who don't have access to the server directory.
For example, you could place the following snippet in your application's orion-application.xml file in order to have the log write out to the /var/oc4j/acmestore.log , as follows :
<log><file path="/var/oc4j/acmestore.log" /></log>
Tip | Absolute file paths aren't very portable across servers and can particularly cause trouble when moving configuration files between Windows and UNIX environments. During development it usually makes sense to use relative file paths if possible. |
By default, when an application writes to System.out or System.err , the output goes to the console. This can be inconvenient if OC4J is running as a background process on a server, or if you need to search the output for a debug message.
In these cases, you can redirect either or both to log files by passing command-line parameters to oc4j.jar like this:
java -jar oc4j.jar -out log/acmestore-out.log -err log/acmestore-error.log
Tip | If you need a finer level of control over application logging, take a look at the Apache Jakarta Log4J project ( http://jakarta.apache.org/log4j/ ) or the new logging facilities in Java 1.4. |
Many times it's difficult to debug an application problem without figuring out how a particular request was handled by OC4J. Table 4-5 lists debug parameters that can be passed in to OC4J as system properties. When enabled, each logs additional useful debug information.
Log File | Description |
---|---|
http.session.debug | Logs HTTP session events (for example, session creation, invalidation , and so on); useful when debugging logout sequences and other session-related code |
http.cluster.debug | Logs HTTP clustering events |
http.error.debug | Logs HTTP errors |
datasource.verbose | Logs data source and connection information; useful for troubleshooting connection leaks or sizing connection pools |
jdbc.debug | Logs JDBC calls; useful for debugging SQL errors |
ejb.cluster.debug | Logs EJB clustering messages |
transaction.debug | Logs transaction information; useful for debugging rollback exceptions, deadlocks, and data inconsistencies |
rmi.debug | Logs extra RMI information; useful when debugging client applications or communication between J2EE components applications on different servers |
rmi.verbose | Logs even more RMI information |
jms.debug | Logs extra JMS information |
For example, to debug a database connection leak, you might enable data-source logging to see when connections were being opened and released, as shown here:
java -Ddatasource.verbose -jar oc4j.jar
| ||