Do not use the ATG ApplicationLogging API

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.

JBoss logging and ATG

I’m describing the obvious I guess. However it took me longer than expected. So for the occasional clueless (like me in 2 months time when I forgot this)

The Dynamusic 🙂 examples use console logging with debug message type. However if you use JBoss, setting GLOBAL.properties in DAS will not help you…..

JBoss logging is configured with log4j.xml in the atg server configuration. The entry:
<appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
<errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
<param name="Target" value="System.out"/>
<param name="Threshold" value="INFO"/>
<layout class="org.apache.log4j.PatternLayout">
<!-- The default pattern: Date Priority [Category] Message\n -->
<param name="ConversionPattern" value="%d{ABSOLUTE} %-5p [%c{1}] %m%n"/>
</layout>
</appender>

Has loglevel INFO. So debug statements will not pass through. At first I thought to create a nucleus category with priority DEBUG. I haven’t looked it up in the Log4j docs, but it seems it is not possible to set logging priorities lower than the appender threshold. Sounds logical…

So changing the threshold

<param name="Threshold" value="DEBUG"/>

Will get the ATG debug statements through the console.

Adding

<category name="org.jboss">
<priority value="INFO"/>
</category>

Keeps all those JBoss debug statements out.