Coding Recommendations 

The logic so far is straightforward, just a few additional code lines, and you can obtain the decent result in a log file. Before moving on to the next section, there are certain recommendations for you to improve the tracing functions.

Static Reference

As is shown in the Simple Example Flow, the variable that holds the location object is declared with a static modifier to improve efficient access. Basically, a handle to a location object can always be obtained by calling Location.getLocation(<id>). However, making such a call every single time may reduce performance.

Hierarchical Naming Convention

It is good to create a static variable for the trace object and it is a useful and easy approach to name the <name of the location object> as the complete package path of the class, for both the clarity and inheritance features available in the SAP Logging API.

When naming a location object for your Java class, it is a straightforward approach if you use a hierarchical naming convention, such as the fully qualified name. This not only avoids ambiguity on classes having the same name, but also takes full advantage of the inheritance feature (for example, on severity level and output destination) implemented by the logging framework.

The class com.sapmarkets.foo is parent to classes com.sapmarkets.foo.classA and com.sapmarkets.foo.classB, and the latter two classes are siblings.

In this case, the severity level and the logs assigned to the parent com.sapmarkets.foo will become effective for its children com.sapmarkets.foo.classA and com.sapmarkets.foo.classB. Siblings will not affect each other.

To avoid problems connected with the potential typing error of a lengthy correct class name that will affect the inheritance features, there is another API for Location.getLocation(<java class>), which accepts a class other than a string.