!--a11y-->
Relations Between Category and
Location 
It is common practice to look at the log and trace messages together when you perform a diagnosis. A correlation between a problematic logical area and the source code location that generates the problem is highly desired. For example, an error occurs when closing the database. The actual location of the source code (from which class, which method, with what argument(s)) is also reported.
For more information about how this can be supported to generate both log and trace messages in parallel with the use of a category and a location, see Message Output with Severity.
This example only shows the attachment of a location to a category (it refers to the location being associated to the category, as relative of the category,) but this is also true for the opposite case.

The SAP Logging API supports precisely the assignment of a category to a location and also the other way round, but not among the same type. It is legitimate to associate more than one category to a location at each logging, but only one location for one category. For more information about each class, see the output method APIs of each class.
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 objMgmt = Category.getCategory("/Objects/Management"); public void announce(Object o) { final String method = "announce(java.lang.Object)"; loc.entering(method, new Object[] { o }); try { // Register object ... } catch (RegistrationException e) { objMgmt.errorT(loc, method, "Error registering object {0}.", new Object[] {o}); } loc.exiting(); } // method announce } // class Node |
In order to output all the trace and log messages presented in the example above, you have to implement the following severity setting:
loc.setEffectiveSeverity(Severity.PATH); objMgmt.setEffectiveSeverity(Severity.ERROR);
conLog = new ConsoleLog(); loc.addLog(conLog); |
The category objMgmt outputs two messages simultaneously – one log message and one trace message. These messages have the same message ID for cross-referencing each other. This makes the analysis more comfortable.
There is a possibility for the configuration to have already been defined in the initialization stage and to be effective to this local scope through the hierarchical inheritance logic. For more information, see Typical Practice for a Better Style, Hierarchical Severity Inheritance, and Hierarchical Destination Inheritance.
If the location has a stricter severity setting, for example default Severity.NONE, the trace output will be suppressed, including the one from the category. That is, that output line will not produce two messages simultaneously, but only the log message.
It is possible to have a more advanced configuration regarding the correlated category and location source objects. Consider, for example, some extreme situations in the /Objects/Management category, that is, messages with severity FATAL. Several source code locations (com.sapmarkets.xxx.a, com.sapmarkets.xxx.b, and so on) can result in a fatal condition in this logical area. But for this extreme situation you are interested in one of them in particular, for example com.sapmarkets.xxx.a, and would like to generate more output messages, including all with severity INFO or above related with this location only, while maintaining FATAL for the rest.
Having a tight severity control initially and then relaxing it for particular areas in terms to produce more output for analysis is essential. For more information about how to achieve this using the relative severities, see Relative Severities.