Configuring Logging

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.

Table 4-4: Log Files

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.

Configuring Log Filenames and Locations

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.

Redirecting Standard Output and Error Streams

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.

Using OC4J Debug Parameters

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.

Table 4-5: Debug Parameters

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 


Oracle Application Server 10g. J2EE Deployment and Administration
Oracle Application Server 10g: J2EE Deployment and Administration
ISBN: 1590592352
EAN: 2147483647
Year: 2004
Pages: 150

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net