Andreas Schaefer's Blog

To the Hell with the JDK Logging: II

After several futile attempts to get my deployment units to log to Glassfish I finally figured out to use Log4J in Glassfish which is not really well documented there. So that is what I had to do:

1. Place log4j.jar and log4j.properties file somewhere (I put it into <Glassfish Home>/lib/log)
2. Add the fully qualified path to the log4j.jar into the classpath of Glassfish together with the directory that contains the log4j.properties file. You can do that in the web UI: Application Server/JVM Settings/Paths and the entries are separated by a return.
3. Restart the server

Now you will find the log file relative to the <Glassfish Domain Directory>/config directory. Now I can read the log4j output like usual even though not in the same file as the Glassfish log statements.

Now some feedback to the responses I got:

1. I could use SLF4J but this does not help for the classes provided by ServiceMix and that are the more important logging statements
2. Well, Log4J was here first and so many projects and products were using Log4J way before JDK 1.4. And because logging is such a wide spread component so it the pain the incompatibility is causing.
3. If Sun had provided a superior implementation that Log4J I could bite the bullet but they did not and so the whole idea of the JDK logging is ridiculous. And therefore I also don't want a JSR because that is making it even more painful.

Moral of the story is that if Sun could have swallowed their pride and either kept Log4J out of the JDK or just incorporated Log4J as is like they did with Corba we would not have this discussion. Now we have several frameworks on top of them that are trying to fix that and each of them fail one way or the other, what a mess. Thank you - Sun.

Comments

• While the current situation is a pain, was Sun the only party with an excess of ego? One significant difference between the frameworks is that log4j localises at the time a log event is created, whereas java logging can delay localisation, potentially to the point where the log is viewed.

  Posted by: mthornton on August 29, 2007 at 01:09 AM

• Hi Andreas - Let's make sure that we add your request for a future release of GlassFish. In the meantime w should document your workaround in the FAQ that is about to start this week. - eduard/o

  Posted by: pelegri on August 29, 2007 at 07:20 AM

• Hi, my question is why log4j ignores JSR-000047 Logging API Specification?
  

  Posted by: hlavki on August 29, 2007 at 09:06 AM

• 
  Wow!

  Sure is a lot of hate about JDK Logging going around past couple of days.

  
  JDK Logging's curse is that it's just too simple for folks, and that simplicity comes through in "lack of features", even though JDK Logging is as wide open as anything. There is one "hard coded" fact about JDK Logging that can't be changed by the application, and that's the 7 logging levels.

  
  EVERY OTHER PART of JDK Logging is changeable at runtime and through the application. The whole thing. JDK Logging can do anything you want.

  
  If there a specific piece of the JDK Logging you're not happy with, it is readily changeable.

  
  Loggers, Handlers, Formatters, Filters, LogRecords, and LogManager. That's it! That's the whole system. All in a bubbling soup. LogRecords fed to Loggers with Filters and handed off to Handlers with more Filters and Formatters, and a LogManager at the front with a baton to handle routing and hierarchy. All the rest is sugar on top. Don't like their sugar, add your own.

  
  I did, I added a simple Logger wrapper because JDK Logging is cursed by having come out in JDK 1.4, and using Object arrays for parameters rather than varargs.

  
  You want Glassfish system logs to log through Log4j? Add a LogManager, and a Logger implementation that routes through Log4j. There, shazam, all of Glassfish is running through Log4j, and it doesn't even know about it. No need to recode Glassfish, no need to convert anything. You change a property on the command line and Everything is Different while still being oh so familiar.

  
  Commons-logging took the wrong approach layering on top of the various logging systems, when it should have simply changed the plumbing that JDK Logging provides, and then provide a sugary layer on top of JDK Logging.
  

  Posted by: whartung on August 29, 2007 at 10:17 AM

• My apologies for the issues with ServiceMix using JCL. Just this week we had a conversation about this very topic on the dev list and determined that we will replace JCL with SLF4J in ServiceMix 4.0.

  BTW, just yesterday I posted a blog entry of my issues with JCL and JUL and why I like SLF4J if you're interested:

  http://bsnyderblog.blogspot.com/2007/08/my-soapbox-for-slf4j.html

  Posted by: bsnyder on August 29, 2007 at 04:14 PM

• 
  Thanks for the info. It helped me solve one of my problems. I found that log4j can also be configured very easily for an instance on Windows XP Pro by doing the following:

  Place log4j.xml in ${com.sun.aas.instanceRoot}/config
  Place log4j.jar in ${com.sun.aas.instanceRoot}/lib/ext
  Restart server.

  Defining a file appender with the values below (note the file location), also allows you to select the file for searching via the normal SJSAS admin console.

  file location="${com.sun.aas.instanceRoot}/logs/log4j.log"
  ConversionPattern = "[#|%d{yyyy-MM-dd'T'HH:mm:ss.S'+1000'}|%p|appname|%c|_ThreadName=%t|%m|#]%n"

  I have not tried this on a Unix box yet, will do that tomorrow.
  

  Posted by: steyng on August 29, 2007 at 11:32 PM

• The worst thing with log4j is the need for a configuration file. I have
  lost count of the number of jars that I have had to clean up to remove
  the cutAndPaste log4j.properties (and sometimes for good measure
  log4j.xml) stuck in the root of the jar file, trashing all the other log4j.properties
  files.

  Posted by: peterkittreilly on August 30, 2007 at 04:22 AM

• @whartung:

  JUL.Level is extensible:
  "It is possible for third parties to define additional logging levels by subclassing Level."
  

  Posted by: apmarki on February 09, 2008 at 02:58 AM

This work is licensed under a Creative Commons License.