Understanding severity levels

The severity of a message refers to how severe the problems is. All InfoSphere® MDM Custom Domain Hub messages are associated with a severity level.

Error codes severity levels are defined in the CDERRSEVERITYTP table. By default most problems defined for a customer do not have an explicit severity; instead, this is interpreted by the application as a fatal severity level. If the application encounters one or more errors with a severity level of fatal while executing a persistence transaction, it rolls back the transaction and returns the errors in the response.

The com.dwl.base.logging.IDWLLogger interface introduces logging severity levels. The following table shows how IDWLLogger levels are mapped to Log4J and Java™ logger levels:

Although there are 13 levels shown in the table, InfoSphere MDM Custom Domain Hub only uses six levels. Developers building their own extensions, additions, or external rules should follow the same guidelines when logging their messages.

• ERROR – Indicates severe error events that lead the application to abort. Here are some typical examples:
  • A system level error is caused by a throwable object
  • Any system failure is due to a programming error such as null pointer exception, or missing mandatory configuration
• WARN – Indicates potentially harmful situations, but the application continues to run. These situations are of interest to end-users or system managers
• INFO – Indicates informational messages that are understandable to end-users and system administrators, such as information about the execution flow through major controller- and component-level methods (for example, in preExecute and postExecute methods, and also in the entry and exit points of external rules).
• CONFIG – Indicates messages that provide a variety of static configuration information to assist in debugging problems that may be associated with particular configurations (for example, information on the application version, properties versions, database type and version, and others).
• FINE – Indicates fine-grained information events that are most useful to debug the application, and are broadly interesting to developers who do not have a specialized interest in the specific subsystem; for example, logging SQL statements, high-level Rules of Visibility messages, external rules, business validations that are client's error, and others.
• FINER – Indicates very granular informational events. In general, Finer should be used for detailed tracing messages, such as showing low-level Rules of Visibility messages, any logging within loops, and similar items.

Each logging API allows the level to be configured for run time to control the level of detail in the log destination. This level can be set at any level within the logger hierarchy ranging from root; that is, the global or application level, to any package, subpackage, or class level. See the respective API documentation for more information on how to do set the levels.

It is important that the level is set to an appropriate value based on the runtime environment. If the level is more granular, the level provides more detail but slows the application performance. On the other hand, only capturing the error level logs, reduces, or even eliminates, most messages with the exception of errors, making the application faster but more difficult to debug. The default level setting is an error, and the following are guidelines for runtime environment messages:

• For development environment messages, use FINER to CONFIG.
• For testing environment messages, use:
  • ERROR for faster performance but less information about the error.
  • INFO or WARNING for more information about the error but slower performance.
• For production environment messages, use ERROR.