LF5 User Guide

- Overview
- Features
- Reading Files
- Configuration
- Library
- Examples
- Troubleshoot
- FAQ

Log4j Project

- Home page

Troubleshooting Examples

> Q. How do I send log messages to both LogFactor5 and a rolling log file?

> A. Log4J gives you the ability to log to mulitple appenders. The RollingFileAppender class is the appender used to log messages to a series of files. The following code snippet shows how to configure a log4j.properties file or a standard properites file so that it logs to both the LogFactor5 console and a rolling log file.

>     # Register both appenders
>     with the root of the logger tree.

>     log4j.rootLogger=, A1, R

>     # A1 is set to be a LF5Appender which outputs to a swing
>     # logging console.

>     log4j.appender.A1=org.apache.log4j.lf5.LF5Appender

>     # R is the RollingFileAppender that outputs to a rolling log
>     # file called rolling_log_file.log.

>     log4j.appender.R=org.apache.log4j.RollingFileAppender
>     log4j.appender.R.File=rolling_log_file.log

>     # Configure a pattern layout, the size of the file and the number
>     # of backup files.

>     log4j.appender.R.layout=org.apache.log4j.PatternLayout
>     # Edited to fit.
>     log4j.appender.R.layout.ConversionPattern=[slf5s.start]%d{DATE}[slf5s.DATE]%n\
>       %p[slf5s.PRIORITY]%n%x[slf5s.NDC]%n%t[slf5s.THREAD]%n\
>       %c[slf5s.CATEGORY]%n%l[slf5s.LOCATION]%n%m[slf5s.MESSAGE]%n%n
>     log4j.appender.R.MaxFileSize=100KB
>     log4j.appender.R.MaxBackupIndex=1

> For more information on logging to multiple appenders along with a demo, please see the IntiUsingMultipleAppenders example in the examples folder.

> Q. What is the maximum number of log records that will be visible at any one time?

> A. The logging console will only display up to 5000 LogRecords as a default. When this limit has reached, the oldest record will be removed from those that are displayed.

> Q. Is the maximum number of records shown configurable?

> A. The maximum number of records shown is configurable via a log4j properties file, or via the Configure menu item in the LogFactor5 GUI. Our memory profiling has shown that with a logging message of 25 words in length, and a stack trace nested seven methods deep, every 1000 records displayed in the logging console uses about 6 MB of memory. For this reason, when you are setting the maximum number of log records to be shown, it is possible to run out of memory if you are not careful. The default maximum number of records is set to 5000 records to minimize the possibility of running out of memory.

> Q. Why does the command prompt hang when I close the console?

> A. If you close the LogFactor5 console (as opposed to exiting) you are effectively hiding the console and turning off any logging to console. However, closing the console does not shut down the Java virtual machine. As a result, the command prompt hangs until the virtual machine is properly shut down.

> Q. How do I shut down the console completely including the virtual machine?

> A. Selecting exit (as opposed to close) will shut down the LogFactor5 console along with the virtual machine.

> Q. I have not added LogFactor5 via a configurator or the addAppender() method, yet the console still pops up every time. What's happening?

> A. The example log4j.properties file that ships with LogFactor5 is in your CLASSPATH, and is being loaded during static initialization of the Category class. If you remove the file from your CLASSPATH, or rename the file, the logging console should stop loading.

> Q. If I close the LogFactor5 logging console, but don't shut down the virtual machine (i.e. use close rather than exit) does the console continue to log messages?

> A. No. Once the LogFactor5 console is closed, it stops logging messages. This does not effect any other appenders you may be using (i.e. rolling log files).

> Q. When I call the removeAppender( ) method on the Category class, the logging window does not disappear. What's happening?

> A. The LF5Appender is being removed from the list of registered Appenders in the Category class, and messages are no longer being sent to the logging window. However, the logging window is being kept alive by the Swing thread, so you will need to close the window manually in order to get rid of it.

> Q. How do I send log messages to LogFactor5 using log4j's SocketAppender and SocketServer classes?

> A. Log4 gives you the ability to send messages to a remote location over a socket for logging purposes. The org.apache.log4j.net.SocketAppender and org.apache.log4j.net.SocketServer classes are the key classes used in remote logging.

> If you want to use the LF5Appender to log messages remotely, you can simply register the LF5Appender in the properties file being loaded by your SocketServer. The following steps give you a high level description of how to do this. For more information on using the SocketAppender, along with a demo, please see the UsingSocketAppenders example in the examples folder.

> STEP 1: On the client side (the application producing the logging messages), modify your configuration properties file to write to a SocketAppender. If you add lines similar to the following to your configuration file, it should do the trick:

>         log4j.rootCategory=, A1
>         log4j.appender.A1=org.apache.log4j.net.SocketAppender
>         log4j.appender.A1.RemoteHost=localhost
>         log4j.appender.A1.Port=8888

> Once you have loaded this configuration, all messages will be written to the machine and port that you specify.

> STEP 2: On the server side (where you are listening for messages), you will need to run log4j's SocketServer class. You should create a configuration file with configuration information similar to the following:

>         log4j.rootCategory=DEBUG,A
>         log4j.category.org.apache.log4j.net.SocketNode=DEBUG
>         log4j.appender.A=org.apache.log4j.lf5.LF5Appender

> STEP 3: Set up your CLASSPATH on both the client and server to run log4j and LogFactor5.

> STEP 4: Run the SocketServer at the command line. The command line syntax for the SocketServer is as follows:

>         java org.apache.log4j.net.SocketServer portNumber configurationFile\
>                                                configurationDirectory

> For example, we ran the following at the command line: java org.apache.log4j.net.SocketServer 8888 C:\temp\socketserver.properties C:\temp

> STEP 5: Start your client, and start logging messages to the SocketAppender.

> Q. How do I save my current configuration?

> A. LogFactor5 has a Configure menu item in the top menu bar. If you choose save from this menu, it will save your current configuration. If you choose reset from this menu, it will delete any saved configuration information.

> Q. What configuration information is saved?

> A. If you choose Configure->Save from the LogFactor5 menu, LogFactor5 saves the configuration of the category explorer window. This means that the next time you open LogFactor5, any channels that you have selected or de-selected will remain as they were when you last exited the GUI.

> Q. When I open LogFactor5, I have a bunch of old categories from another application. What's going on here, and how do I get rid of these dead categories?

> A. You must have saved your configuration in the other application. LogFactor5 is displaying your saved configuration, as well as any new categories in the application you are now running. To remove these empty categories, right-click at the root of the category tree in the category explorer window, and choose "Remove All Empty Categories". If you want to get rid of this old configuration information permanently, you should choose Configure->Reset from the menu as well.

> Q. I'm using Ant to build my project and one of my tasks is to execute a series of JUnit tests. When I attempt to use the LF5Appender as an appender I get the following exception thrown:

>         java.lang.NullPointerException
>         at javax.swing.ImageIcon.<init>(ImageIcon.java:134)
>         at org.apache.log4j.lf5.viewer.channelexplorer.ChannelNodeRenderer.
>                                            <init>(ChannelNodeRenderer.java:71)
>         ... etc.

> What do I need to do to fix this problem?

> A. This problem is related to the way that Ant's class loader works. The solution for this problem is to fork the junit task into a separate Java Virtual Machine. The appropriate code to fork the VM is a follows:

>         <junit fork="yes">
>           ...
>         </junit>

> Q. When I try to open a file, I get the following error: 'Error - Invalid log file format!'. What is going on?

> A. LogFactor5 can read in log files created with Log4J's RollingFileAppender. The format of the log file must follow the LogFactor5 layout conventions in order for LogFactor5 to open the file. For more information on LogFactor5's layout conventions and how to set the conversion pattern in a Log4J properties file, please see the OpeningLogFiles example.

> Q. Why can't I set my own custom date format?

> A. Log4j allows users to cutomize the date format of their log records. Unfortunately LogFactor5 does not support this feature. LogFactor5 uses a date manager to ensure that only one date format is ever used. The reason for this is that LogFactor5 can read in log files created with Log4J's RollingFileAppender. However, the data in the log files is text rather than objects. In order for LogFactor5 to read in the log file, it must know the exact format of the data in order to parse the information. This include the format of the date. Any files containing invalid date formats would not be able to be opened and read. As a result, users are forced to use a default date format provided by Log4j ( %d{Date} ).

> Q. Why does the LogFactor5 GUI hang when I use Tomcat 1.4's reload feature to reload my application?

> A. When an application using LogFactor5 is deployed using Tomcat, the GUI binds itself to the naming context of the application. However, when the application is reloaded using Tomcat's reload feature, the naming context is nulled and a new naming context is created. Since the VM is not shut down and restarted during the reload process, and there is no longer a naming context to bind to, the LogFactor5 console hangs. When the application is reloaded, a new LogFactor5 console is created while the old one is left hanging in limbo. One way around this problem is to use Tomcat in conjunction with JBoss to redeploy the application. JBoss also has a reload feature that allows users to redeploy their application without having to bounce the web/application server. The difference is that JBoss has a naming context manager that keeps track of an applications naming context between deploys rather than nulling the context and creating a new one. As a result, the LogFactor5 console will remain bound to the application between each deploy.

Copyright © 1999-2004, Apache Software Foundation