log4j, an open-source API from the Apache Software Foundation, is a simple yet effective solution for enabling logging for Java applications. With log4j, you can include inheritance-based logging, configurable at runtime, without modifying the code base.
This tip explains the configuration and packaging options for log4j for applications that run on Sun Java System Application Server 7 (formerly Sun ONE Application Server 7 and hereinafter called Application Server 7). It contains the following sections:
You can add log4j for the applications that run on all the instances of Application Server 7 or for the applications that run on one particular Application Server 7 instance only.
Global Configuration
Making the log4j API available in the applications that run on all the instances of Application Server 7 involves two major steps:
- Place the log4j Java archive (JAR) file in an instance-independent location of the Application Server 7 installation.
- Add the JAR file to each instance's class path.
Specifically, do the following:
- Place the JAR file for log4j in the installation_dir
/lib directory, where
installation_dir is the root directory of the Application Server 7 installation.
- Log in to the Application Server Administration Console (port 4848 by default).
- On the right pane, click a server instance that is running applications that will use
the log4j API.
The property settings screen for that instance is displayed.
- Click the JVM Settings tab.
The screen for setting the Java virtual machine properties is displayed.
- Click Path Settings.
The screen for defining paths is displayed.
- Define the path for the JAR file, as follows:
- If the Classpath Suffix text field is empty, type in the absolute path to the log4j JAR:
installation_dir/lib/log4j-version_number.jar
where:
- installation_dir is the root directory of the Application Server 7 installation.
- version_number is the three-digit version number of log4j. At this time, that number is 1.2.8; therefore, the file name reads:
log4j-1.2.8.jar.
- If the Classpath Suffix text field already shows a list of JARs, append to that list with the absolute path to the
log4j-version_number.jar file. Follow this syntax:
list_of_JARs; installation_dir/lib/log4j-version_number.jar
- Click Save.
A message, which is also a hot link, is then displayed at the top right-hand corner:
Restart Required.
- Click the Restart Required link at the top right-hand corner.
A screen that lists the instance name, host name, and other information is then displayed, along with this message:
Apply Changes and Restart Required Configuration changes have not yet been applied. "Apply Changes" and restart the instance to make these changes effective.
- Click Apply Changes--the rightmost button above the message.
- Click Restart to restart the Application Server 7 instance to enable the configurations to take effect.
- For all other server instances that are running applications to which you'd like to add the log4j API, repeat steps 2 through 10.
Instance-Specific Configuration
In case only the applications that run in a particular instance of Application Server 7 will use log4j, add log4j to the class path of that instance. This approach ensures that log4j is loaded by the Common Classloader and made available to the applications of that instance.
You need not package the log4j JAR with each of the applications that run in this instance. Just perform one step: Place the log4j JAR file in this directory:
installation_dir/domains/your_domainname/your_instancename/lib
After a restart of the newly configured Application Server 7 instance, the applications and their components on the Application Server instance you specified will be able to call the log4j API. You need not add the log4j JAR to the instance's class path.
You can include log4j with deployments of enterprise application archives (EARs) or Web application archives (WARs) in many ways. The goal is to ensure that the components that are based on the Java 2 Platform, Enterprise Edition (J2EE platform) in the application, which contain calls to the log4j API, can successfully call that API.
Packaging of WARs
Packaging log4j with a WAR is straightforward. Simply place the log4j JAR in the WAR's WEB-INF/lib directory. In turn, the Web Classloader loads log4j, and the log4j API is then available to all the pages in your application that are built with the JavaServer Pages (JSP) or Java Servlet technology.
You need not explicitly add a Class-path: entry in the WAR's META-INF/manifest.mf file.
Packaging of EARs
For a broad leverage of the log4j API across a J2EE application, place the log4j JAR in the root directory of your EAR to allow access by components that are based on Enterprise JavaBeans (EJB), JSP, or Java Servlet technology.
For example, suppose you have a EAR that can be extracted as the following:
MyEJB.jar
MyWebApp.war
META-INF/
Copy the log4j JAR to the root of the EAR. The contents of the EAR then become the following:
MyEJB.jar
MyWebApp.war
META-INF/
log4j-version_number.jar
However, that step alone is not sufficient and, when application components call the log4j API, will result in an error (java.lang.NoClassDefFoundError). To circumvent that issue, add or revise the Class-path: entry to the EJB JAR's
META-INF/manifest.mf file so that the entry includes the log4j JAR. Here is the syntax:
Class-path: log4j-version_number.jar; additional_JAR_needed
Note - You can add as many JAR references to this manifest entry as required by other APIs.
Thanks to the parent-child relationship of the EJB and Web Classloaders in Application Server 7, once you have added the log4j JAR to the Class-path: entry, the log4j API automatically becomes available to the WAR components. You need not drop the log4j JAR in the WEB-INF/lib directory or add a Class-path: entry in the WAR's META-INF/manifest.mf file.
For details on the Application Server 7 Classloaders, see the section, "Classloaders" in the Application Server 7 Developer's Guide.
Matthew Litkey is a member of technical staff of Market Development Engineering at Sun. He works with independent software vendors to develop and integrate applications with Sun Java Enterprise System. Matt graduated from Villanova University, where he served as president of the Villanova Association for Computing Machinery (ACM). In his spare time, Matt enjoys composing and performing music and the theatrical arts.
Jay Galvin is a senior member of technical staff of Marketing Development Engineering at Sun. He works with independent software vendors to develop and integrate applications with Sun Java Enterprise System.
Marina Sum is a staff writer for Sun Developer Network. She has been writing for Sun for 15 years, mostly in the technical arena.
|