Robust event logging with Syslog

Syslog is a fast, flexible, and easily extendable logging system

1 2 3 Page 3
Page 3 of 3

Keep in mind that you can make all these configuration changes at any time without altering a single line of source code in the system. You could even modify the configurations while the system is running. If a given component has problems, start logging all messages coming from that component to a separate log file by using the FileLog logger and the PerClassPolicy log policy, which can filter messages based on the class name producing the message, to select messages.

If the messages do not need to obey transaction contexts in the application server, then simply replace the JMSLog with the RemoteLog in the application server(s) and modify the log server configuration accordingly -- a very simple change. Messages will be sent via RMI instead of across a JMS topic. Again, multiple servers can receive those messages.

Syslog and other systems

If you need to configure Syslog from inside another server or application, simply call the Syslog.configure() method and pass in a reference to the desired configuration file. You can also configure Syslog programatically: add, remove, and reconfigure loggers while the system is running using methods in the Syslog class and the individual loggers.

Configuration files

A basic Syslog configuration file looks like this:

  <Syslog defaultMask="DEBUG">
    <Logger name="myPrintWriterLog"
      class="com.protomatter.syslog.PrintWriterLog"
    >
      <stream>System.out</stream>
      <Policy class="com.protomatter.syslog.SimpleLogPolicy">
        <channels>ALL_CHANNEL</channels>
        <logMask>INHERIT_MASK</logMask>
      </Policy>
      <Format
class="com.protomatter.syslog.SimpleSyslogTextFormatter">
        <showChannel>true</showChannel>
        <showHostName>false</showHostName>
      </Format>
    </Logger>
    <!-- as many logger definitions as needed -->
  </Syslog>

The <Syslog> tag in the configuration file must be either the document's root element or a direct child of the root element so that Syslog's configuration will integrate with other XML-based systems in the same document.

The defaultMask attribute of the <Syslog> tag must be DEBUG, INFO, WARNING, ERROR, or FATAL. The default log mask is set to accept messages at or above the given level. If this parameter is omitted, the default log mask sets to WARNING.

The <Logger> tag inside the <Syslog> tag specifies a name for each logger, which should be unique, and a Syslogger implementation to use. After the class loads, its default constructor is called, then the logger is named, and the <Logger> element passes to the configure() method so that the logger can configure itself. All XML structures are passed around using JDOM objects.

Syslog will produce the default configuration and write it out to the console if the com.protomatter.syslog.Syslog class invokes from the command line. It will also parse and validate any configuration file passed in as the first command line argument. Default values are also filled in, and the resulting configuration prints to the console.

Conclusion

Syslog has evolved over time into a robust system for handling logging in a wide variety of Java applications. In this article, you've learned how to easily integrate Syslog into a Java program without carrying references to loggers in code that need to perform logging. You've also learned how to reconfigure Syslog while a system is running. In addition, configuration files can manipulate all aspects of log message handling, which eliminate code changes. Syslog saves valuable development time by eliminating the need for developers to reinvent the wheel each time a new system is built and deployed. Moreover, using Syslog in many projects makes it easier for an operations department to handle successive deployments because there is no need to learn how to configure each new system.

Nate Sammons is a freelance Java developer who has been writing server-side Java applications since the Servlet API first appeared, and has worked with BEA's WebLogic Server since it was called Tengah. He currently lives in the Boston metro area, but is planning a return to Denver soon.

Learn more about this topic

1 2 3 Page 3
Page 3 of 3