Digital Sanctuary

Digital Sanctuary
ATG Logging Guidelines
This document is the property of Digital Sanctuary and contains private and/
or proprietary information. It may not be used or disclosed except pursuant to
a written agreement.

General Logging Policies

Proper logging is critical not only for debugging and sustainment, but also for SOX compliance (if
needed) and security audit trails.
Never use System.out or e.printStackTrace methods. They are not only messy but are also exploitable by log-forging techniques or other attacks.
All ATG logging calls must be wrapped within an if(isLoggingXXX()) block. This improves performance.
Never log any data points which would be considered PII, CPNI, PCI relevant, etc..., unless it
would be impossible to diagnose a problem without the data. These data points must also never be
logged anywhere other than debug.
The only log level which can include a stack trace is error.
Logging activation, i.e. loggingXXX=true or false, must never be checked into the code repository.
Log settings are environment specic, and must never be checked in.
There must not be any cross-component logging conguration, i.e.:
loggingDebug^=nucleus/path/to/some/other/Component.loggingDebug
Log lines must be prexed with their class and method names in the format of:
ClassName.methodName(): log message
If the method is overloaded in that class, please include the input signature of the method, i.e.:
ClassName.methodName(String, List): log message

This document is the property of Digital Sanctuary and contains private and/or proprietary information.

Digital Sanctuary

ATG Log Level Guidelines

Debug:

Debug logging should provide detailed information on the ow through the system. This level is to
be used when the application needs to be debugged and any information which the developer
might nd useful can be outputted. Note that you should not have to turn on debug in order to understand for example why a job failed. Messages like that should be presented at the warning level.
This is the only log level which may contain any private or more sensitive data points, and even
then, only include those data points when having them is required for debugging issues.
Info:

Interesting runtime events. Be conservative and keep to a only useful information, such as when a
user is authenticated or when a resource starts a major task. For example, global service starts and
stops should be logged here. Messages should only be one-liners (no stack traces or xml dumps).
Warning:

Use the warning level priority for events that may indicate a non-critical service error. Resumable
errors, or minor breaches in request expectations fall into this category. The distinction between
warning and error may be hard to discern and so its up to the developer to judge. The simplest criterion is would this failure result in a user support call. If it would use error. If it would not use
warning. Messages should only be one-liners (no stack traces or xml dumps).
Error:

Use the error log level for fatal system errors or user impacting failures. Any situation where a user
is unable to complete an action through no fault of their own or a critical component or interface
failure. Error logs can include stack traces.

Non-ATG Logging
Any logging outside of the ATG framework, for instance logging from a non-component, or from
third party code, must use the Commons Logging library, or a wrapper around it (such as log4j,
etc...). There is an ATG component which provides a Commons Logging to ATG Logging bridge.
com.digitalsanctuary.util.CommonsLoggingATGBridge.java is the class.
Trace logging is rolled up into debug logging in ATG, and Fatal logging is rolled down into Error
logging in ATG. Please use the guidelines above, and break out logging to Trace and Fatal as you
see t, as long as it still meets the standards of Debug and Error, respectively.

This document is the property of Digital Sanctuary and contains private and/or proprietary information.