Pankaj Kumar's Weblog

I spent better part of today fighting with a JBoss-4.0.2 idiosyncracy with regard to its handling of Logger class during shutdown.
Here is a brief explanation of the problem, the diagnosis and how I fixed it.

The Problem

I have a JBoass XMBean compliant MBean (meaning it extends JBoss class ServiceMBeanSupport) that initialized a Logger object with a special FileHandler, Formatter and other configured values for log file, level etc. This object worked as expected in most cases, but not all. Specifically, all log invocations, directly or indirectly, from the stopService() of the MBean did not produce any output when the JBoss was shutdown with "$JBOSS_HOME/bin/shutdown.sh -S" command. Interestingly, these invocations worked just fine when stopService() was invoked either directly or through the the JBoss's JMX Console.

The Diagnosis

My first diagnosis was that the shutdown command was not calling the stopService() method. But I had to reject this diagnosis after seeing System.out.println() output from this method. Then I got suspicious about the identity of the Logger object. However, a println of the Logger object address confirmed that it was the same object in both startService() and stopService(). The next step was to print various attributes of the logger object -- level, handlers etc. This helped in pin-pointing the problem. The getLevel() method was returning null (it should have been Level.INFO).

So, JBoss is traversing the tree of Loggers and resetting them before calling stopService() method of deployed MBeans!

The Fix

The only fix I could think of was to keep my Logger object away from the Logger hierarchy manitained by JDK logging library and hence the JBoss. But how to do that?

That is when I stumbled upon getAnonymousLogger() method. Replacing the call Logger.getLogger("mylogger") with Logger.getAnonymousLogger() did the trick and allowed my cleanup code to be run with proper log messages.