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.

ATG 2007.1 on Mac OS X with MySQL

For some weeks now ATG 2007.1 is available. My entry about installing ATG on Mac OS X explained how to install ATG 2006.3 on Mac OS X Tiger which is not supported by ATG . It got a few hits, so perhaps an update is needed.

Pre installation

• Have jboss-4.0.5GA ready. This is the only version supported by ATG 2007.1.
• Have MySQL ready. Only 5.0.20 is supported. However I have used 5.0.45 and so far it seems to be working fine. Make sure you use the InnoDB engine instead of the MyISAM.
• Create an ATG user on MySQL in a way you seem fit
• Add export JBOSS_HOME=<your JBOSS 4.0.5GA path here> to .bash_login. If you use another shell, you know what to do.
• Take care of your permissions.
• Download ATG2007.1 for Unix

Installation and configuration

• Run ATG2007.1.bin
• When asked to enter the path where to install ATG, remove the space. It will make things easier.
• When asked for JAVA_HOME use /System/Library/Frameworks/JavaVM.framework/Versions/ 1.5.0/Home or your preferred version.
• Drop your license files in <ATG folder>/home/localconfig
• Add the following line export ATGJRE=/System/Library/Frameworks/JavaVM.framework/ Versions/CurrentJDK/Commands/java to dasEnv.sh
• Copy MySQL JDBC driver (mysql-connector-java-5.0.7-bin.jar) to <JBOSS_HOME>/server/atg/lib
• Add a mysql-ds.xl to <JBOSS_HOME>/server/atg/deploy and fill in the correct database name etc.
• Create a file, like this: /home/localconfig/atg/dynamo/service/jdbc/JTDataSource.properties
  The ATG documentation states to create a jbossconfig folder with a change to a manifest to point to that path. I skipped that.
• Edit this JTDataSource.properties. It should contain:
  JNDIName=java:/MySqlDS
  and
  $class=atg.nucleus.JNDIReference
• Run datascripts:
  • /Applications/ATG2007.1/DAS/sql/install/mysql/das_ddl.sql
  • /Applications/ATG2007.1/DPS/sql/install/mysql/dps_ddl.sql
  • /Applications/ATG2007.1/DSS/sql/install/mysql/dss_ddl.sql
  • /Applications/ATG2007.1/DCS/sql/install/mysql/dcs_ddl.sql

  I used mysql -D <dbname> < /Applications/ATG2007.1/DAS/sql/install/mysql/ das_ddl.sql --user=<username> --password=<password>

Some notes

Adding Darwin to <ATG folder>/home/bin/DynamoEnv.sh is not something I use anymore as I did in 2006.3. I will assume Solaris. This will make patching easier, as Robert Hellwig found out.

Unlike ATG 2006.3 ATG2007.1 JTDatasource.properties can contain $class=atg.nucleus.JNDIReference

The executing of the SQL scripts was not correct in the previous Blog. The user and password command was wrong. Why didn’t anybody tell me?

On the previous blog entry, I got some questions on how you can tell MySQL to use InnoDB. Check your my.cnf or my.ini file. It’s in the ATG documentation:

Debugging Nucleus components in JBoss with Eclipse

It seems that ATG developers are creatures of old habits. Most of them use VI or Emacs because they are used to it. Perhaps because they think it is better…. Only my observation of course. For all I know a lot of them are using Textmate with their custom ATG bundles.

And debugging? : through debug logging statements…

Since Java 1.2 we have the Java Platform Debugger Architecture. It amazes me how few are using it..

If you don’t know how to debug with JPDA when developing for ATG on JBoss with Eclipse it’s easy:

• First start JBoss with debugging enabled. Do this by adding the line:

JAVA_OPTS="$JAVA_OPTS -Xdebug -Xrunjdwp:transport=dt_socket, address=5000,server=y,suspend=n"

to the run.conf file in the <JBOSS_HOME>/bin folder and then

• create a debug configuration in Eclipse. Use the Remote Java Application, Socket Attach. Use the port as defined in the JAVA_OPTS. Port 5000 in this example.

It should look something like this:

Happy debugging

JBoss startup errors

Finally I got around to remove some errors which were visible during JBoss ATG startup.

One of them was:
FATAL [JspServletOptions] The scratchDir you specified: ……… is unusable (or something along that line)

This one is solved by setting the permissions correctly. A chown will solve this. I guess you won’t see such an error on Windows..

The other one was a [URLDeploymentScanner] Incomplete Deployment listing on jboss-xa-jdbc.rar.
I have no idea how to get rid of that one, but since I won’t be doing Distributed datasource there is actually no problem….I think.

[EDIT]

Got rid of that one also. Somehow a jboss-xa-jdbc.rar folder folder was inside the deploy folder of JBoss. Yes a folder with folder in the name. Removing that one solved the problem. (of course you have to keep the jboss-xa-jdbc.rar there)

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.