|
The Java Flexible Logging Toolkit (or JFLT for short) is a standalone Java library developed by Tivoli for the TMX4J v 2.1 software package. It provides a flexible architecture for supporting different logging mechanisms. This document describes how using this logging facility for capturing the message logging produced by the TMX4J base libraries. A brief description of the basic components of the JFLT toolkit is provided below for educational and informational purposes only.
The main objective of this logging toolkit is to allow developers to specify which (user-defined) log mechanism to use for message logging in the TMX4J libraries. This is useful in environments in which the JMX-based application is already developed for using a specific logging toolkit and/or the configuration is changed through an external mechanism. In this way it is possible to "capture" and integrate the TMX4J message logging with the application runtime environment (for instance writing logging to the same physical device, such as a console, file, or socket).
The JFLT API may be appropriate for developing in a standalone fashion simple applications too. In fact JFLT provides a set of useful message logging methods that can be used by developers for making easier the writing of their logging code. For instance, a developer could write MBeans basing their internal log mechanism on the JFLT architecture. These MBeans, together with the JFLT JAR file, can be deployed in different environments and managed through different implementations of the JMX specification. In non-TMX4J-based environments, if the message logging is enabled, only the MBean's logging information will be written on the specified logfile. When instead they are managed through the Tivoli's implementation of the JMX, the message logging is also integrated with the log produced by the JMX infrastructure.
JFLT consists of multiple java packages. For
convenience, all these packages have been included in
one independent JAR file (jflt.jar
) that must be specified on the
CLASSPATH
when launching a JFLT-based application. Note that you can avoid
to set this way the CLASSPATH
with a
TMX4J-based application if the logging JAR file is located in the
same directory as jmxc.jar
(for more details on this issue see the
following
The following two scenarios are intended to give a
perspective of how the flexible logging
mechanism can accomplish specific programming requirements and make easier the task to insert
logging into JFLT-based (or JMX-based)
applications.
Providing JMX-based facilities for WebSphereTM
Suppose that WebSphere system management architects want to provide administration facilities for measuring the performance and availability of server platforms, Web servers, and application servers. They could have to develop a new WebSphere application that exploits JMX agent-based monitoring methods for enabling customers to have visibility into their e-business infrastructure inside a DMZ. Using the TMX4J JFLT logging facility they should only implement few lines of code for integrating all the JMX log output with the existing WebSphere runtime environment and maintain in such a way a centralized point for controlling the logging produced by all involved application components.
A computer programming developer, call him Max, is responsible for adding JMX support to a Web application for an Application Server. The application uses the API of a proprietary Java library to log messages. Max's customers, the administrators responsible for his server application at customer sites and the L3 people who answer those administrator's support calls, only want to deal with a single log file. Therefore Max's minimum requirement is for a way to direct JMX logging to the appropriate log file; but what he would really like is to be able to plug JMX infrastructure into Application Server logging mechanism in such a way that he could control JMX logging via the Application Server runtime environment (i.e. the Application Server configuration settings) and the systems management functionality provided by the runtime. Also in this case TMX4J represents an easy solution to solve the problem.
In the previous scenarios we used Application Servers examples just to make it concrete with regards to important integration requirements. But TMX4J is able to support scenarios where Mary chooses Log4J for her application while Max uses JLog in his. Both want to provide management solutions integrating JMX agent-based monitoring in their products but they do not want to deal with multiple log files and logging configuration settings. For all that, TMX4J can really represents a valid solution.
In order to get more information on how JFLT works and how configuring the logging in TMX4J see the following documentation.
Java Flexible Logging Toolkit API Specification
Configuring and Using TMX4J Logging
|