● Location – fatalT, errorT, warningT, infoT, pathT, debugT.
● Category - fatalT, errorT, warningT, infoT.
The names concerning the severity level of the messages, generated by these methods are self-explanatory. The overloaded pattern is the same for each severity output. In the table below, the pattern is masked with ‘xxxx’:
Basic Methods
Location |
Category |
xxxxT(String message) |
xxxxT(Location loc, String message) |
xxxxT(String subloc, String message) |
xxxxT(Location loc, String subloc, String message) |
xxxxT(String message, Object[] args) |
xxxxT(Location loc, String message, Object[] args) |
xxxxT(String subloc, String message, Object[] args) |
xxxxT(Location loc, String subloc, String message, Object[] args) |
There is a pattern in the method overloading that revolves around the core argument – the message. The addition of subloc and args offers flexibility for logging messages at the level of details that they need. Understanding these arguments can make it easier for you to select the heavily overloaded methods:
Arguments
Name |
Description |
loc |
The only difference in the API between the location and the category is an additional loc argument in the category output methods. It is a typical request that log messages are always written with respect to a source code area. This proves to be very helpful for the logging analysis. By specifying the loc argument, you indicate that the message must be written as a trace message associated with the loc object. This works for a location as well, and the API can specify the category argument. More information: Relations Between Category and Location. |
subloc |
Treat the subloc argument as the method name of the source class, from which the message is generated. This is optional, but including this argument in the trace/log, makes the analysis more clear. In particular, you can specify different arguments for overloaded methods. |
message |
The actual message to be printed is put in the argument message. |
args |
An array of additional arguments that are informative. This is achieved by using the java.text.MessageFormat API to resolve arguments. |
package com.sap.fooPackage;
import com.sap.tc.logging.*;
public class Node { private static final Location loc = Location.getLocation("com.sap.fooPackage.Node"); public void announce(Object o) { String method = "announce(java.lang.Object)"; try { // do something...e.g. connecting to DB, perform certain actions // it will not be logged, severity DEBUG is lower than WARNING loc.debugT(method, "Connecting to ….“); //minor error in writing something loc.warningT(method, "Problems in row {0} to {1}“, new Object[] {row1, rowN}); //error in the connection loc.errorT(method, "DB connection failure“); } catch (Exception e) { } } // method announce } // class Node |
Potential output, assuming the simplest case with ConsoleLog and default TraceFormatter:
May 3, 2001 6:54:18 PM com.sap.fooPackage.Node.announce [main] Warning: Problems in row 15 to 18 May 3, 2001 6:54:18 PM com.sap.fooPackage.Node.announce [main] Info: DB connection failure |
package com.sap.fooPackage;
import com.sap.tc.logging.*;
public class Node { private static final Location loc = Location.getLocation("com.sap.fooPackage.Node"); private static final Category cat = Category.getCategory("/System/Database"); public void store() { try { // Write object data to database ... } catch (FailedRegistrationException e) { cat.errorT(loc, "store()", "Error storing node {0} in database.", new Object[] {this}); } } // method store } // class Node |
The output is identical to the “Working on a Location Object”, assuming the default setting (with ConsoleLog and default TraceFormatter).
More information: Basic Features.