JRas extension classes
WAS provides a base set of implementation classes that are collectively referred to as the JRas extensions. Many of these classes provide the appropriate implementations of loggers, handlers, and formatters for use in a WAS environment.
The JRas framework described in this task and its sub-tasks is deprecated. However, we can achieve similar results using Java logging.
The collection of JRas classes is targeted at an integrated mode of operation. If we choose to use the JRas extensions in either stand-alone or combined mode, we can reuse the logger and manager class that are provided by the extensions, but provide our own implementations of handlers and formatters.
WAS message and trace loggers
The message and trace loggers that are provided by the stand-alone JRas logging toolkit cannot be directly used in the WAS environment. The JRas extensions provide the appropriate logger implementation classes. Instances of these message and trace logger classes are obtained directly and exclusively from the WAS Manager class. We cannot directly instantiate message and trace loggers. Obtaining loggers in any manner other than directly from the Manager class is not allowed and directly violates the model.
The message and trace logger instances that are obtained from the WAS Manager class are subclasses of the RASMessageLogger and RASTraceLogger classes that are provided by the stand-alone JRas logging toolkit. The RASMessageLogger and RASTraceLogger classes define the set of methods that are directly available. Public methods that are introduced by the JRas extensions logger subclasses cannot be called directly by user code because it is a violation of the programming model.
Loggers are named objects and are identified by name. When the Manager class is called to obtain a logger, the caller is required to specify a name for the logger. The Manager class maintains a name-to-logger instance mapping. Only one instance of a named logger is ever created within the lifetime of a process. The first call to the Manager class with a particular name results in the logger, which is configured by the Manager class. The Manager class caches a reference to the instance, then returns it to the caller. Subsequent calls to the Manager class that specify the same name result in a returned reference to the cached logger. Separate namespaces are maintained for message and trace loggers. Use a single name obtain both a message logger and a trace logger from the Manager, without ambiguity, and without causing a namespace collision.
In general, loggers have no predefined granularity or scope. A single logger can be used to instrument an entire application. We might determine that having a logger per class is more effective, or the appropriate granularity might be somewhere in between. Partitioning an application into logging domains is determined by the application writer.
The WAS logger classes that are obtained from the Manager class are thread-safe. Although the loggers provided as part of the stand-alone JRas logging toolkit implement the serializable interface, loggers are not serializable. Loggers are stateful objects, tied to a Java virtual machine instance and are not serializable. Attempting to serialize a logger is a violation of the programming model.
Personal or individual logger subclasses are not supported in a WAS environment.
WAS handlers
WAS provides the appropriate handler class used to write message and trace events to the WAS run time logs. We cannot configure the WAS handler to write to any other destination. The creation of a WAS handler is a restricted operation and is not available to user code. Every logger that is obtained from the Manager comes preconfigured with an instance of this handler already installed. We can remove the WAS handler from a logger when you want to run in stand-alone mode. When you remove it, we cannot add the WAS handler again to the logger from which it is removed or any other logger. Also, we cannot directly call any method on the WAS handler. Attempting to create an instance of the WAS handler, to call methods on the WAS handler or to add a WAS handler to a logger by user code is a violation of the model.
WAS formatters
The WAS handler comes preconfigured with the appropriate formatter for data that is written to WAS logs. The creation of a WAS formatter is a restricted operation and not available to user code. No mechanism exists that allows the user to obtain a reference to a formatter installed in a WAS handler, or to change the formatter a WAS handler is configured to use.
WAS manager
WAS provides a Manager class in the com.ibm.websphere.ras package. All message and trace loggers must be obtained from this Manager class. A reference to the Manager class is obtained by calling the static Manager.getManager method. Message loggers are obtained by calling the createRASMessageLogger method on the Manager class. Trace loggers are obtained by calling the createRASTraceLogger method on the Manager class.
The manager also supports a group abstraction that is useful when dealing with trace loggers. The group abstraction supports multiple, unrelated trace loggers to register as part of a named entity called a group. WAS provides the appropriate systems management facilities to manipulate the trace setting of a group, similar to the way the trace settings of an individual trace logger work.
For example, suppose component A consists of 10 classes. Suppose each class is configured to use a separate trace logger. All 10 trace loggers in the component are registered as members of the same group, for example, Component_A_Group. We can turn on trace for a single class, or we can turn on trace for all 10 classes in a single operation using the group name, if we want a component trace. Group names are maintained within the namespace for trace loggers.
Related tasks
Programming with the JRas framework
Related
JRas Extensions