| Oracle® Containers for J2EE Configuration and Administration Guide 10g (10.1.3.4.0) Part Number E12288-01 |
|
|
View PDF |
| Oracle® Containers for J2EE Configuration and Administration Guide 10g (10.1.3.4.0) Part Number E12288-01 |
|
|
View PDF |
This chapter provides instructions on using the system and application logging features available in OC4J. It covers the following topics:
Configuring Application Loggers with Application Server Control
Redirecting log4j Messages for an Application to the OC4J Log
Each OC4J process generates a number of log files to aid in troubleshooting. If multiple processes are running for an OC4J instance, multiple sets of log files are generated.
OC4J can generate two types of log files:
Plain text log files
Plain text logs are the default log files used for OC4J components, and are ideal for use in a development environment. The messages logged in these text files can be read with any editor or with Oracle Enterprise Manager 10g Application Server Control.
Oracle Diagnostic Logging (ODL) log files
The messages logged in these files use an XML format that is viewable with Application Server Control. ODL supports log file rotation.
Log files are generated in different locations, depending on the component or application that data is being recorded for. The logging configuration for each component or application is defined in component-specific XML configuration files.
Table 11-1 lists the names and locations of the various log files generated, as well as the XML configuration file containing the logging configuration for each component. Unless otherwise indicated, all paths indicated are within ORACLE_HOME/j2ee/home for standalone OC4J or ORACLE_HOME/j2ee/instance for OPMN-managed OC4J instances.
Table 11-1 List of Log Files Generated for OC4J
| Component | Configuration File | Default Log File Name and Location |
|---|---|---|
|
OC4J component using Java logging |
See "Configuring OC4J Logging" for details on configuring this ODL-formatted log file. |
Standalone OC4J: /log/oc4j/log.xml OPMN-managed OC4J: /log/instance_default_group_1/ oc4j/log.xml
|
|
Application Server Control |
/application-deployments/ascontrol/ orion-application.xml |
Standalone OC4J: /log/ascontrol-application.log OPMN-managed OC4J: /log/instance_default_group_1/ ascontrol-application.log
|
|
Application deployed to OC4J |
/application-deployments/app_name/orion-application.xml
|
Standalone OC4J: /application-deployments/app_name/application.log
OPMN-managed OC4J: /application-deployments/app_name/instance_default_group_1/ application.log |
|
Global ( |
/config/application.xml |
Standalone OC4J: /log/global-application.log OPMN-managed OC4J: /log/instance_default_group_1/ global-application.log
|
|
Default Web site access logging |
/config/default-web-site.xml |
Standalone OC4J: /log/default-web-access.log OPMN-managed OC4J: /log/instance_default_group_1/ default-web-access.log
|
|
OC4J server |
/config/server.xml |
Standalone OC4J: /log/server.log OPMN-managed OC4J: /log/instance_default_group_1/server.log
|
|
JMS |
/config/jms.xml |
Standalone OC4J: /log/jms.log OPMN-managed OC4J: /log/instance_default_group_1/jms.log
|
|
RMI |
/config/rmi.xml |
Standalone OC4J: /log/rmi.log OPMN-managed OC4J: /log/instance_default_group_1/rmi.log
|
|
OPMN |
|
|
Through the oc4j.properties file, you can configure an OC4J instance to generate trace files to a specific debug destination instead of the default destination. Oracle Application Server does not support the configuration of two different OC4J instances to generate trace output to the same destination, even if the instances are in the same group. Each OC4J instance manages its own trace files.
Plain text logging is the default format used in OC4J.
This mechanism separates messages in alignment with the XML files. However, instead of writing to multiple log files of the same size, all messages for that component are written into a single log file. The following topics describe how to use text logging:
Text logging is enabled or disabled through elements in the XML configuration files listed in Table 11-1, except for the default-web-site.xml file. (See "Configuring Web Site Access Logging" for details on configuring Web site access logging.)
Logging is enabled via the <file> subelement of the <log> element of the XML configuration file for each component. The element contains a single path attribute which specifies the name and optionally the location of the log file generated:
<log> <file path="application.log" /> </log>
To turn off text logging for a component, remove or comment out the <file> element from the appropriate configuration file. If you do not remove this line and you enable ODL, both logging options will be enabled.
For example, to disable text logging for an application, comment out the following <file> element in the application's orion-application.xml file:
<log> !-- <file path="application.log" /> --> </log>
Although both ODL and text logging can be enabled simultaneously, one of these options should be disabled to save disk space.
It is important to monitor your log files, as text logging does not have any imposed size limits or log rotation capability. If left unchecked, log files will continue to grow and can overrun the disk.
The only way to manage these files is to stop OC4J, remove the files, and then restart OC4J to start the log files over.
All text log files are generated by default in the locations listed in Table 11-1. Text log files are identified by the log extension.
Text log files generated for OC4J components can be viewed with Application Server Control, as follows:
Click the Logs link at the bottom of any Application Server Control page.
Expand OC4J.
Expand <instanceName>. The default instance name is home.
Text log files for deployed J2EE applications cannot be viewed with Application Server Control.
The Oracle Diagnostic Logging framework, or ODL, provides plug-in components that complement the standard Java framework to automatically integrate log data with Oracle log analysis tools.
In the ODL framework, log files are formatted as XML documents, enabling logs to be parsed and reused by other Oracle Application Server and custom-developed components, including Application Server Control. In ODL, unlike in text-based logging, log file rotation is supported.
ODL is enabled by adding the <odl> element within the <log> element in any of the XML files listed in Table 11-1.
Notes:
You can enable ODL for an application at the time the application is deployed by setting values for odls in the log property through the deployment plan editor.
See the Oracle Containers for J2EE Deployment Guide for details on configuring an application using the deployment plan editor.
ODL for Web sites uses a different configuration. For more information about this configuration, see "Configuring Web Site Access Logging".
Both ODL and text file logging can be enabled simultaneously. However, you should disable one of these options to save disk space.
The <odl> element has the following attributes. All are required.
path: The path to the directory where the log.xml files for this component will be generated.
Important:
Specify the path as ../log/appName, as the next example shows. This path is required for viewing log files with Application Server Control.
max-file-size: The maximum size, in kilobytes, that an individual log file is allowed to grow to. When this limit is reached, a new log file is generated.
max-directory-size: Sets the maximum size, in kilobytes, allowed for the log file directory. When this limit is exceeded, log files are purged, beginning with the oldest files.
For example, the following entry in the petstore application's orion-application.xml file will cause log.xml files to be generated for this application. It will also set log files to a maximum of 1,000 KB and the directory maximum to 10,000 KB.
<log> <odl path="../log/petstore/" max-file-size="1000" max-directory-size="10000" /> </log>
Using this configuration, petstore log files will be generated in the following locations, depending on your OC4J installation.
Standalone OC4J:
Log files will be generated in ORACLE_HOME/j2ee/home/application-deployments/log/petstore.
OPMN-managed OC4J:
Files will be generated in an OC4J instance- specific directory named ORACLE_HOME/j2ee/instance/application-deployments/log/instance_default_group_1/petstore.
The ODL framework provides support for managing log files, including log file rotation. The maximum log file size and the maximum size of log directories can also be defined. In addition, using ODL provides these benefits:
You can limit the total amount of diagnostic information saved.
Older segment files are removed and newer segment files are saved in chronological fashion.
Components can remain active and do not need to be shut down when diagnostic logging files are cleaned.
An ODL log is a set of log files that includes the current log file, log.xml, and zero or more ODL Archives (segment files), which contain older messages. After you enable ODL, each new message is added to the end of log.xml. When this log file reaches the rotation point, it is renamed and a new log.xml file is created.
Segment files are created when the current log file reaches the rotation point, specified by the maximum ODL segment size, and for some OC4J logs, the rotation time and rotation frequency. Thelog.xml file is renamed to logn.xml, in which n is an integer, starting at 1. The new log.xml file is created when the component generates new diagnostic messages.
When the last log file is full, the following procedure occurs:
The oldest log file is erased to provide space in the directory.
The log.xml file is written to the latest logn.xml file, in which n increments by one over the most recent log file.
To limit the size of an ODL log for an application or component, you can use a configuration option specifying the maximum size of the logging directory. Whenever the sum of the sizes of all of the files in the directory reaches the maximum, the oldest archive is deleted to keep the total size under the specified limit.
Note:
The most recent segment file is never deleted.For example, when the maximum directory size is reached, with the starting segment file named log9872, the following files could be present in the log file directory:
File Size log.xml 10002 log9872.xml 15000 log9873.xml 15000 log9874.xml 15000 log9875.xml 15000 log9876.xml 15000
In this case, when log.xml fills up, log9872.xml is removed and log.xml is moved to the new file log9877.xml. New diagnostic messages are then written to a new log.xml file.
For example, to specify the maximum ODL segment size and maximum directory size for an OC4J application named petstore, you would add the following entry to the file ORACLE_HOME/j2ee/instance_name/application-deployments/petstore/orion-application.xml:
<log> <odl path="../log/petstore/" max-file-size="1000" max-directory-size="10000" /> </log>
For OC4J components that are configured in the j2ee-logging.xml file, you can specify a rotation time and rotation frequency, in addition to a maximum segment size and directory size.
For time-based log rotation, you can specify the following properties in a <log_handler> subelement of the <log-handlers> element of the <logging-configuration> root element:
baseRotationTime: (Optional.) The base time for the rotation. The format for the base time can be any of the following:
hh:mm, for example, 04:20. This format uses the local time zone.
yyyy-MM-dd, for example, 2006-08-01. This format uses the local time zone.
yyyy-MM-ddThh:mm, for example 2006-08-01T04:20. This format uses the local time zone.
yyyy-MM-ddThh:mm:ss.sTZD, where TZD is the timezone indicator. TZD can be Z, indicating UTC, or {+|-}hh:mm. For example, 2006-03-01T04:20:00-08:00 represents March 1, 2006 4:20:00 in US Pacific Standard Time time zone.
If you do not specify baseRotationTime, the default value is Jan. 1, 1970, 00:00 UTC.
rotationFrequency: The frequency of the rotation, in minutes. In addition, you can specify one of the following values: hourly, daily, or weekly.
You specify these properties in the following file:
ORACLE_HOME/j2ee/instance_name/config/j2ee-logging.xml
For example, to specify that the log files are rotated every day at 4:00AM local time, or when they reach 2000000 bytes in size, use the following:
<log_handler name="h1" class="oracle.core.ojdl.logging.ODLHandlerFactory">
<property name="path" value="log"/>
<property name="baseRotationTime" value="04:00"/>
<property name="rotationFrequency" value="daily"/>
<property name="maxFileSize" value=" 2000000"/>
</log_handler>
ODL-formatted log files can be viewed by clicking the Logs link in Application Server Control, enabling administrators to aggregate and view the logging output generated by all components and applications running within OC4J from one centralized location.
ODL log files are identified in the Log Files page by the .xml extension.
Click the Logs link at the bottom of any Application Server Control page.
Expand OC4J.
Expand <instanceName>. In both standalone OC4J and OAS, the default instance name is home.
To view the OC4J log files, expand Diagnostic Message Logs, then open log.xml.
To view ODL logs for a specific J2EE application:
Expand Application <applicationName> .
Expand Diagnostic Message Logs. Open and view the log.xml file generated within this director.
The various components of OC4J utilize Java loggers that write to the OC4J log file. The OC4J log file is generated in XML format using the Oracle Diagnostic Logging framework and can be viewed with Application Server Control.
The section covers the following topics:
OC4J provides a number of component loggers that write to the OC4J log file (log.xml). You can view and configure the available component loggers on the Logger Configuration page of Application Server Control.
The Java log level can be set for each individual component logger. If set to NULL, a logger inherits the log level set for its parent.
Therefore, the default level for all loggers is INFO, which maps to the NOTIFICATION Java log level, as that is the default value inherited from the oracle logger. See "Configuring the oracle Logger" for details on changing this default value.
The log level set on a logger through the Logger Configuration page is not persisted, but is applied to the OC4J runtime only. When OC4J is restarted, the log level reverts back to the default setting inherited from the parent logger.
Table 11-2 illustrates the log levels that you can set with Application Server Control as well as the ODL message type:log level that each Java log level maps to.
Table 11-2 Log Levels for OC4J Component Loggers
| Java Log Level | ODL Message Type:Log Level | ODL Description |
|---|---|---|
NULL |
The logger will inherit the log level set for its parent. |
|
SEVERE |
ERROR:1 |
Log system errors requiring attention from the system administrator. |
WARNING |
WARNING:1 |
Log actions or conditions discovered that should be reviewed and may require action before an error occurs. |
INFO |
NOTIFICATION:1 |
Log normal actions or events. This could be a user operation, such as login completed, or an automatic operation, such as a log file rotation. |
CONFIG |
NOTIFICATION:16 |
Log configuration-related messages or problems. |
FINE |
TRACE:1 |
Log trace or debug messages used for debugging or performance monitoring. Typically contains detailed event data. |
FINER |
TRACE:16 |
Log fairly detailed trace or debug messages. |
FINEST |
TRACE:32 |
Log highly detailed trace or debug messages. |
To configure OC4J component loggers with Application Server Control:
Click the Administration link.
Click Logger Configuration.
Set Log Level to a value listed in the left-hand column of Table 11-2.
Click Apply to apply your changes to the OC4J runtime.
The OC4J log file can be viewed with Application Server Control. To view the file:
Click the Logs link at the bottom of any Application Server Control page.
Expand OC4J.
Expand <instanceName>.
Expand Diagnostic Message Logs.
As with all ODL log files, each new message goes into the current log file, named log.xml. Once the maximum size is reached, the log is copied to an archival log file, named logn.xml, in which n is an integer starting at 1.
The configuration for the oracle logger is defined in j2ee-logging.xml, which is installed in the ORACLE_HOME/j2ee/instance/config directory.
To configure the oracle logger with Application Server Control:
On the OC4J Home page, click Administration.
From the administration tasks, select Logger Configuration to display the Logger Configuration page.
Click Expand All to view the entire list of loggers currently loaded for the OC4J instance.
Select a log level for any of the loggers shown on the page.
To configure the oracle logger in j2ee-logging.xml:
You can also edit the j2ee-logging.xml configuration file by hand. Restart OC4J after making any changes to this file.
The configuration file contains two elements within the <logging-configuration> root element:
<log_handlers>
This element includes <log_handler> elements defining three different log handlers:
oc4j-handler
This is the log handler for the oracle logger.
oracle-webservices-management-auditing-handler
This is the log handler for the oracle.webservices.management.auditing logger.
oracle-webservices-management-logging-handler
This is the log handler for the oracle.webservices.management.logging logger.
The following properties are specified in <property> subelements for each log handler:
path: Specifies the directory in which the handler will generate log files. Do not modify this value.
maxFileSize: Sets the maximum size, in bytes, that any log file in the directory will be allowed to grow to. When a file exceeds this limit, a new file is generated.
maxLogSize: Sets the maximum size, in bytes, allowed for the log file directory. When this limit is exceeded, log files are purged, beginning with the oldest files.
<loggers>
This element includes a <logger> element defining the following:
name: The logger name. Do not modify this value.
level: The minimum log level that this logger acts upon. This level is set by default to the ODL NOTIFICATION:1 value, which maps to the INFO Java log level displayed on the Logger Configuration page in Application Server Control.
You can set this value to either a Java logging level (FINE) or an ODL Message Type:Log Level (TRACE:1).
useParentHandlers: Indicates whether or not the logger should use its parent handlers. Because this value is set to false by default, the oracle logger does not inherit the log level set for its parent, the root logger.
<handler>: The name of the handler to use. Do not modify this value.
The following example sets the default log level to FINEST by specifying TRACE:32 as the ODL Message Type:Log Level.
<logging_configuration>
<log_handlers>
<log_handler name='oc4j-handler'
class='oracle.core.ojdl.logging.ODLHandlerFactory'>
<property name='path' value='%ORACLE_HOME%/j2ee/%OPMN_PROC_TYPE%/log/
%OPMN_PROC_TYPE%_%OPMN_PROC_SET%_%OPMN_PROC_INDEX%/oc4j'/>
<property name='maxFileSize' value='10485760'/>
<property name='maxLogSize' value='104857600'/>
</log_handler>
</log_handlers>
<loggers>
<logger name='oracle' level='TRACE:32' useParentHandlers='false'>
<handler name='oc4j-handler'/>
</logger>
</loggers>
</logging_configuration>
You can direct application log messages into the OC4J logging system and view them in Application Server Control with LogViewer. If you use the standard JDK logging API, you can configure logging handlers and log levels to direct the log entries from an application into ORACLE_HOME/j2ee/instance/log/oc4j/log.xml, the main OC4J log. LogViewer lists this log in Application Server Control as Diagnostic Logs.
To view application messages in the OC4J log with LogViewer:
In an application, set up a logger to issue log messages at different levels, using a logger naming hierarchy, as follows.
Example 11-1 Application Logger to Set Up Different Log Levels
Logger logger = Logger.get("emp.app.web.EmployeeFrontEnd");
public void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException,
IOException {response.setContentType(CONTENT_TYPE);
logger.fine(
String.format("Handling web request for %s", request.getRequestURL()));
PrintWriter out = response.getWriter();
out.println("<html>");
out.println("<head><title>EmployeeFrontEnd</title></head>");
out.println("<body>");
Employee test = Employee.getTestInstance();
logger.finest(
String.format("Test Employee Instance: %s", test));
logger.finest(
String.format("Calling %s to locate office for %s",
employeeManager.toString(),
test.identifier(test.ID_SHORT)));
String location = employeeManager.locateEmployeeOffice(test);
logger.finest(
String.format("bean returned %s for %s ",
location, test.identifier(test.ID_SHORT)));
out.printf("<p>Employee: %s</br>Office: %s</p>", test.identifier(test.ID_SHORT), location);
logger.fine(String.format("Employee currently earns $%s", test.getSalary()));
test.raiseSalary(15D);
out.printf("<p>Give employee 15percent raise, now earns %s", test.getSalary());
out.println("</body></html>");
out.close();
}
In the <logging_configuration> element of the j2ee-config.xml file, add a new <logger> element that specifies the application logger name and logging level and declares the logger to use oc4j-handler, as in the following example:
<logging_configuration>
<log_handlers
<log_handler name="oc4j-handler"
class="oracle.core.ojdl.logging.ODLHandlerFactory">
<property name="path" value="../log/oc4j"/>
<property name="maxFileSize" value="10485760"/>
<property name="maxLogSize" value="104857600"/>
<property name="encoding" value="UTF-8"/>
<property name="supplementalAttributes" value="J2EE_APP.name,
J2EE_MODULE.name,WEBSERVICE.name,WEBSERVICE_PORT.name"/>
</log_handler>
</log_handlers>
<loggers>
<logger name="oracle" level="NOTIFICATION:1" useParentHandlers="false">
<handler name="oc4j-handler"/>
<handler name="console-handler"/>
</logger>
<logger name="emp" level="FINEST
<handler name="oc4j-handler"/>
</logger>
</loggers>
</logging_configuration>
Any messages written to the oracle root logger will be directed to oc4j-handler, which writes messages out in XML format to the ORACLE_HOME/j2ee/instance/log/oc4j/log.xml file.
Click the Logs link at the bottom of any Application Server Control page to list all of the available logs, as Figure 11-1 shows.
Figure 11-1 Logger List in Application Server Control
On the Log Files page, click Diagnostic Logs to have LogViewer display messages from the OC4J log.
As Figure 11-2 shows, the Diagnostic Logs page displays log entries for the OC4J server plus log entries from the application. Each log message shows the component that generated the log entry, such as web_EmployeeFrontEnd or ejb_EmployeeManagerBean.
Figure 11-2 LogViewer Diagnostic Log Page
To view all the log entries for an individual request in sequence, click the Execution Context ID (ECID) link for a log entry.
Based on an ECID assigned to every log message, the Oracle logging framework can correlate various log entries from different components in the same execution path. As Figure 11-3 shows, LogViewer displays all the log entries for the selected ECID in timestamp order.
Figure 11-3 Log Messages for an Execution Context Displayed in Sequence
Use the LogViewer search facilities to search for items of interest in the OC4J log.
After an application has run and its loggers have registered themselves, or after you have configured them in the j2ee-config.xml file, you can use Application Server Control to configure the application loggers. The Logger Configuration page enables you to customize application logging quickly.
To configure application loggers with Application Server Control:
On the OC4J Home page, click Administration.
From the administration tasks, select Logger Configuration to display the Logger Configuration page.
Click Expand All to view the entire list of loggers currently loaded for the OC4J instance.
The OC4J loggers and application loggers are listed, along with a select list that enables you to specify the level for each logger.
Select a log level for any of the loggers listed on the page.
The Oracle Application Server distribution includes a JAR file, ORACLE_HOME/diagnostics/lib/ojdl-log4j.jar, that contains an OracleAppender class. This class is the Oracle log4j appender, which transforms log4j messages into the Oracle Diagnostic Logging (ODL) XML format. Before an application can use this appender, you need to configure it and make the log4j class libraries available to the application.
A log4j.properties file can configure the appropriate log4j settings and the Java log level you want to enable. You can capture and route your log4j entries into the OC4J log system with OracleAppender, as Example 11-2 shows:
Example 11-2 Configuration File for the Oracle log4j Appender
log4j.rootLogger=TRACE,OJDL
log4j.appender.OJDL=oracle.core.ojdl.log4j.OracleAppender
log4j.appender.OJDL.LogDirectory=${oracle.j2ee.home}/log/oc4j
#log4j.appender.APP1.MaxSize=1000000
#log4j.appender.APP1.MaxSegmentSize=200000
#log4j.appender.APP1.Encoding=iso-8859-1
log4j.appender.OJDL.ComponentId=OracleProd
This configuration directs log4j messages into the ORACLE_HOME/j2ee/home/log/oc4j/log.xml file, which LogViewer reads and then displays in Application Server Control as Diagnostics Logs.
After you configure the Oracle log4j appender, you can use the OC4J shared-library mechanism to publish the log4j class libraries to OC4J and then import the libraries into the application.
You can configure the Oracle log4j appender for an application by using the OracleAppender class in the log4j.properties file. Then you can import the configuration into the application during deployment.
To inject the log4j.properties file into an application when you deploy it, you can use the OC4J shared-library mechanism. OC4J reads the properties file from the class path. Importing a shared library that contains the log4j.properties file into an application makes the file accessible to configure log4j for the application.
You can even publish a set of shared libraries that contain different log4j.properties files to OC4J, such as for enabling different log levels, and then choose between the files when the application is deployed. After deployment, you can change the log4j.properties file that the application uses to switch between different logging settings.
To configure the Oracle log4j appender for an application:
Put the log4j.properties file into a JAR file, using a file name that indicates the configured log level, such as log4j.config.info.jar.
Create an OC4J shared library that contains the JAR file.
Figure 11-4 shows how to create a shared library in an OC4J instance with Application Server Control.
Figure 11-4 OC4J Shared Library Containing log4j.properties File
Figure 11-5 shows that two different shared libraries containing a log4j.properties file are available for importing into an application.
Figure 11-5 Shared Libraries for log4j Configuration
Import a shared library that contains the log4j.properties file, such as log4j.config.info, into the application during deployment.
Select Configure Class Loading on the Deployment Tasks page, as Figure 11-6 shows.
Figure 11-6 Configure Class Loading Deployment Task
In the Import Shared Libraries area of the Configure Class Loading page, select a shared library, as Figure 11-7 shows.
Figure 11-7 Shared Libraries for an Application to Import
The log4.info shared library dictates how the log4j log entries for the application will be handled. In this case, the root logger is set to the INFO level, and the OracleAppender class is being employed to direct the log entries into the OC4J log system.
Ultimately, the customized shared-library settings for the application are written to its orion-application.xml configuration file, as Figure 11-8 shows.
Figure 11-8 Shared-Library Settings in orion-application.xml
If you want to change an application to use a lower log level, such as DEBUG or TRACE, then you can modify the <import-shared-library> element in orion-application.xml and restart the application to import the shared library that has the relevant log4j.properties file. Using the OC4J shared-library mechanism and a consistent naming convention should enable you to have as many reusable log4j configurations as you need for your applications.
After you configure the Oracle log4j appender, a single log.xml file will contain any log messages from log4j as well as log entries from OC4J.
Before an application can use the Oracle log4j appender, you need to make the log4j classes available to the application. These classes are in the log4j and ojdl-log4j libraries. You can make the classes available to an application in one of these ways:
Include the libraries in the application.
For a Java EE 5 application, you can use the <library-directory> feature to specify a directory within an EAR file to hold shared libraries and then put the log4j and ojdl-log4j libraries in that directory. In the <library-directory> element of the application.xml file, you specify shared libraries for an application. Then OC4J scans the directories that you specified for archives to include at startup.
Create a shared library in OC4J that contains the log4j and ojdl-log4j libraries and then import the shared library into the application when it is being deployed. After deployment, the libraries will be available to the application.
If you have a Web application, you can put the log4j and ojdl-log4j libraries in the WEB-INF/lib directory for the application to use them.
The ojdl-log4j library has a dependency on the log4j library, so they both have to be accessible at the same class-loader level.
