Digital SanctuaryATG 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 exploit-able by log-forging techniques or other attacks.

All ATG logging calls must be wrapped within an if(isLoggingXXX()) block. This improves per-formance.

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 specific, and must never be checked in.

There must not be any cross-component logging configuration, i.e.:

loggingDebug^=nucleus/path/to/some/other/Component.loggingDebug

Log lines must be prefixed 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

Digital Sanctuary

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

ATG Log Level Guidelines Debug:

Debug logging should provide detailed information on the flow through the system. This level is to be used when the application needs to be debugged and any information which the developer might find useful can be outputted. Note that you should not have to turn on debug in order to un-derstand 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 cri-terion 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 fit, as long as it still meets the standards of Debug and Error, respectively.

Digital Sanctuary

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