This section describes JRas message and trace event types.
Event types
The base message and trace event types defined by the stand-alone JRas logging toolkit are not the same as the "native" types recognized by the WebSphere Application Server run-time. Instead the basic JRas types are mapped onto the native types. This mapping may vary by platform or edition. The mapping is discussed below.
Platform Message Event Types
The message event types that are recognized and processed by the WebSphere Application Server runtime are defined in the RASIMessageEvent interface provided by the stand-alone JRas logging toolkit. These message types are mapped onto the native message types as follows.
WebSphere Application Server native type | JRas RASIMessageEvent type |
Audit | TYPE_INFO, TYPE_INFORMATION |
Warning | TYPE_WARN, TYPE_WARNING |
Error | TYPE_ERR, TYPE_ERROR |
Application developers can use JRas to issue an MVS WTO (write to operator) message by using a JRas RASIMessageEvent type of TYPE_INFO or TYPE_INFORMATION to issue a WebSphere Application Server for z/OS Audit trace. A WebSphere Application Server for z/OS Audit trace maps to an MVS route code 11 WTO.
Platform Trace Event Types
The trace event types recognized and processed by the WebSphere Application Server runtime are defined in the RASITraceEvent interface provided by the stand-alone JRas logging toolkit. The RASITraceEvent interface provides a rich and overly complex set of types. This interface defines both a simple set of levels, as well as a set of enumerated types.
The trace event types are mapped onto the native trace types as follows:
Mapping WebSphere Application Server trace types to JRas RASITraceEvent "Level" types.
WebSphere Application Server native type | JRas RASITraceEvent level type |
Event | TYPE_LEVEL1 |
EntryExit | TYPE_LEVEL2 |
Debug | TYPE_LEVEL3 |
Mapping WebSphere Application Server trace types to JRas RASITraceEvent enumerated types.
WebSphere Application Server native type | JRas RASITraceEvent enumerated types |
Event | TYPE_ERROR_EXC, TYPE_SVC, TYPE_OBJ_CREATE, TYPE_OBJ_DELETE |
EntryExit | TYPE_ENTRY_EXIT, TYPE_API, TYPE_CALLBACK, TYPE_PRIVATE, TYPE_PUBLIC, TYPE_STATIC |
Debug | TYPE_MISC_DATA |
For simplicity, it is recommended that one or the other of the tracing type methodologies is used consistently throughout the application. For users who decide to use the non-level types, it is further recommended that you choose one type from each category and use those consistently throughout the application to avoid confusion.
Message and Trace parameters
The various message logging and trace method signatures accept parameter types of Object, Object[] and Throwable. WebSphere Application Server will process and format the various parameter types as follows.
Controlling message logging
Writing a message to a WebSphere Application Server log requires that the message type passes three levels of filtering or screening.
When a WebSphere Application Server logger is obtained from the Manager, the initial setting of the mask is to forward all native message event types to the WebSphere Application Server handler. It is possible to control what messages get logged by programmatically setting the state of the message logger's mask.
Some editions of the product allow the user to specify a message filter level for a server process. When such a filter level is set, only messages at the specified severity levels are written to WebSphere Application Server logs. This means that messages types that pass the message logger's mask check may be filtered out by the WebSphere Application Server itself.
Controlling Tracing
Each edition of the product provides a mechanism for enabling or disabling trace. The various editions may support static trace enablement (trace settings are specified before the server is started), dynamic trace enablement (trace settings for a running server process can be dynamically modified) or both.
Writing a trace record to a WebSphere Application Server requires that the trace type passes three levels of filtering or screening.
When a logger is obtained from the Manager, the initial setting of the mask is to suppress all trace types. The exception to this rule is the case where the WebSphere Application Server run-time supports static trace enablement and a non-default startup trace state for that trace logger has been specified. Unlike message loggers, the WebSphere Application Server may dynamically modify the state of a trace loggers trace mask. WebSphere Application Server will only modify the portion of the trace logger's mask corresponding to the values defined in the RASITraceEvent interface. WebSphere Application Server will not modify undefined bits of the mask that may be in use for user defined types.
When the dynamic trace enablement feature available on some platforms is used, the trace state change is reflected both in the Application Server run-time and the trace loggers trace mask. If user code programmatically changes the bits in the trace mask corresponding to the values defined by in the RASITraceEvent interface, the trace logger's mask state and the run-time state will become unsynchronized and unexpected results will occur. Therefore, programmatically changing the bits of the mask corresponding to the values defined in the RASITraceEvent interface is not allowed.