|
The integration of the JFLT architecture in TMX4J v2.1 provides flexibility on which logging mechanism the client has to use for developing his JMX-based application. Of course this flexibility provides application architects and developers with the means for integrating a generic logging mechanism inside JMX-based components to be used in several application runtime environments.
In order to set the JFLT library to work with a
particular logging toolkit it is necessary to configure the LogManager
class
with the appropriate manager and message catalog specializations. This configuration is performed through static methods,
as shown in the example below. The following fragment of code shows how much easy is
configuring and using JFLT facility for printing a message:
// Configure the LogManager for using a specialized logging plug-in
LogManager.setManager(new StandardManager(), JlogMessageCatalog.class);
...
// Create a new GenericLogger instance
GenericLogger log = LogManager.getManager().createLogger(
"My Company", "Web Manager Product",
"Enterprise Application XYZ", "mycompany.com.xyz.logger_1",
"myMessageTextFile");
...
// Write a message!
log.message(LogType.TYPE_INFORMATION, this, "main", "key_1");
The GenericLogger
provides the primary interface to the application
programmer by supplying the methods for message logging. The creation of new
loggers is delegated to the LogManager
class that is configured for working with
a particular logging specialization.
A logger must also be told which mechanism has to be used to access the message texts identified by keys. A key is a name for the message text that is usually stored in one or more message files. JFLT provides a customizable mechanism for configuring loggers in different ways to conveniently format the message strings.
For more details on the JFLT programming model and classes description see the JFLT API Specification.
The JFLT architecture provides a logging abstraction
that handles message logging for the client own usage in a flexible
manner. Programmers can easily develop specialized logging mechanism
according to specific application requirements. This task should be enough
straightforward because the JFLT abstraction maps fairly naturally to many
general-purpose logging toolkits. However, TMX4J 2.1 includes a default
adapter based on the Logging Toolkit for Java (JLog)
that can be used for having an
idea of the programming model and rapidly understand
how to develop generic plug-ins. This plug-in is used
when the user does not configure JFLT through the setManager
method.
Of course, the provided JLog-based plug-in implementation, as any other else, can be used for logging messages produced inside the TMX4J base infrastructure (that includes the MBean server, Monitoring services, Timer, Relation service, etc.) and/or following a user code request (for instance from a set of MBeans representing the resources that the JMX-based application has to manage).
The JFLT-to-JLog adapter maintains the compatibility
with the old logging mechanism. Users do
not need to modify their source code when migrating to the TMX4J 2.1 libraries
from a previous release.
This means that the user can continue
to change the logging settings (i.e. enabling/disabling log, changing the
logfile name, setting the appropriate log level, and so on) modifying the property values specified
in the jmx.properties
file. But now he can also control
through this configuration file which mechanism has to be used for logging.
In fact an optional key has been added for defining the default
logging plug-in. In this way the user can modify the logging mechanism
without needing to modify the source code of its JMX-based application! For more
details about this feature see comments included in the
jmx.properties
file and this note.
|