JRas framework (deprecated)
Because the JRas extensions classes do not provide the flexibility and behavior that are 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 WAS run time and the JRas extensions classes.
Handlers
The stand-alone JRas logging toolkit defines the RASIHandler interface. All handlers must implement this interface. You 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 that are provided by the stand-alone JRas logging toolkit. Doing so is a violation of the 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 the formatters and add them to the the 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 the 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 the own trace event types by extending this interface appropriately. In such a case, verify the values for the user-defined trace event types do not collide with the values of the types 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 by 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.
You 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
JRas programming interfaces for logging (deprecated)