WAS v8.5 > Troubleshoot > Add logging and tracing to the application > Programming with the JRas framework

JRas framework (deprecated)

Because the JRas extensions classes do not provide the flexibility and behavior required for many scenarios, a variety of extension points are defined. We can write our own implementation classes to obtain the required behavior.


Deprecated: The JRas framework described in this topic is deprecated. However, we can achieve similar results using Java logging.

In general, the JRas extensions require you to call the Manager class to obtain a message logger or trace logger. No provision is made for you to provide our own message or trace logger subclasses. In general, user-provided extensions cannot be used to affect the integrated mode of operation. The behavior of the integrated mode of operation is solely determined by the WebSphere Application Server run time and the JRas extensions classes.


Handlers

The stand-alone JRas logging toolkit defines the RASIHandler interface. All handlers must implement this interface. We can write our own handler classes that implement the RASIHandler interface. Directly create instances of user-defined handlers and add them to the loggers that are obtained from the Manager class.

The stand-alone JRas logging toolkit provides several handler implementation classes. These handler classes are inappropriate for use in the J2EE environment. We cannot directly use or subclass any of the Handler classes provided by the stand-alone JRas logging toolkit. Doing so is a violation of the programming model.


Formatters

The stand-alone JRas logging toolkit defines the RASIFormatter interface. All formatters must implement this interface. We can write our own formatter classes that implement the RASIFormatter interface. We can add these classes to a user-defined handler only. WAS handlers cannot be configured to use user-defined formatters. Instead, directly create instances of your formatters and add them to the your handlers appropriately.

As with handlers, the stand-alone JRas logging toolkit provides several formatter implementation classes. Direct use of these formatter classes is not supported.


Message event types

The stand-alone JRas toolkit defines message event types in the RASIMessageEvent interface. In addition, the WAS reserves a range of message event types for future use. The RASIMessageEvent interface defines three types, with values of 0x01, 0x02, and 0x04. The values 0x08 through 0x8000 are reserved for future use. We can provide our own message event types by extending this interface appropriately. User-defined message types must have a value of 0x1000 or greater.

Message loggers that are retrieved from the Manager class have their message masks set to pass or process all message event types defined in the RASIMessageEvent interface. To process user-defined message types, manually set the message logger mask to the appropriate state by user code after the message logger is obtained from the Manager class. WAS does not provide any built-in systems management support for managing message types.


Message event objects

The stand-alone JRas toolkit provides a RASMessageEvent implementation class. When a message logging method is called on the message logger, and the message type is currently enabled, the logger creates and distributes an event of this class to all handlers that are currently registered with that logger.

We can provide our own message event classes, but they must implement the RASIEvent interface. You must directly create instances of such user-defined message event classes. When it is created, pass your message event to the message logger by calling the message logger's fireRASEvent method directly. WAS message loggers cannot directly create instances of user-defined types in response to calling a logging method (msg.message) on the logger. In addition, instances of user-defined message types are never processed by the WAS handler. We cannot create instances of the RASMessageEvent class directly.


Trace event types

The stand-alone JRas toolkit defines trace event types in the RASITraceEvent interface. We can provide our own trace event types by extending this interface appropriately. In such a case, ensure the values for the user-defined trace event types do not collide with the values of the types that are defined in the RASITraceEvent interface.

Trace loggers that are retrieved from the Manager class typically have their trace masks set to reject all types. A different starting state can be specified using WAS systems management facilities. In addition, we can change the state of the trace mask for a logger at run-time, using WAS systems management facilities.

To process user-defined trace types, the trace logger mask must be manually set to the appropriate state by user code. WAS systems management facilities cannot be used to manage user-defined trace types, either at start time or run time.


Trace event objects

The stand-alone JRas toolkit provides a RASTraceEvent implementation class. When a trace logging method is called on the WAS trace logger and the type is currently enabled, the logger creates and distributes an event of this class to all the handlers that are currently registered with that logger.

We can provide our own trace event classes. Such trace event classes must implement the RASIEvent interface. You must create instances of such user-defined event classes directly. When it is created, pass the trace event to the trace logger by calling the trace logger's fireRASEvent method directly. WAS trace loggers cannot directly create instances of user-defined types in response to calling a trace method (entry, exit, trace) on the trace logger. In addition, instances of user-defined trace types are never processed by the WAS handler. We cannot create instances of the RASTraceEvent class directly.


User defined types, user defined events and WAS

By definition, the WAS handler processed user-defined message or trace types, or user-defined message or trace event classes. Message and trace entries of either a user-defined type or user-defined event class cannot be written to the WAS run-time logs.


Subtopics


+

Search Tips   |   Advanced Search