KnobsLeversButtons

In my current project we use atg.nucleus.logging.ApplicationLogging. This is with ATG 2007 on JBoss.
At the start it was decided to use the ATG logging API in stead of Log4J (or
any other Java logging framework). ATG and ApplicationLogging was common practice, why not use it I was told.
Later when I saw the code littered with complicated logging statements where the programmer had to include the method from which the Logging statement was executed I was not so sure.

1 Log4J ConversionPattern

Adding the containing method to your logging statement is not necessary. You can use the Log4J ConversionPattern %M in the PatternLayout.
which is used to output the method name where the logging request was issued.
It should be used with care of course since it is a performance drain. But we can alter this at runtime so that’s no biggie (see 2). But…
ATG logging attaches to JBoss logging, however the %M is lost since the ATG logging method is considered as the issuing method. So the
logDebug logInfo, LogError etc, are reported to be the issuing method, in stead of the actual method. Pretty useless.
This would not have happened if ATG ApplicationLogging was not used, but plain Log4J.

2 Different logging level

A used argument is that you can alter the logging level of the individual components in the ATG admin console.
This is trivial. You can also do this in Log4J.xml with the Log4J categories.

3 Dynamic Logging Level

Another argument: You can change the logging level in ATG without restarting the server.
Look at JBoss Log4JService. This automatically picks up changes to Log4J.

Moral

• Don’t use atg.nucleus.logging.ApplicationLogging you butcher Log4J features.
• Don’t think, because you have some patterns which used to work, that that is the best pattern in the future.
  What worked with DAS does not necessarily work with JBOSS.
• Think.