Andreas Schaefer's Blog

August 2007 Archives

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.

To the Hell with the JDK Logging

Based on the success of Log4J Sun for sure had to go ahead and add its own version of it as JDK logging making our life miserable. I was complaining a lot about that at the LA-JUG but today it reached a point where I really had enough to start ranting here.

Currently I am working with Glassfish and beside some other sticky points with it I ran into an issue with the logging or better the absence of logging. What I want to do is to deploy ServiceMix based JBI components as well as our own components to deploy on OpenESB that runs on Glassfish. Something is not working as expected and so I started to look into the log files but could not find any log entries from our applications. Finally I figured out that my component is using Log4J instead of the JDK logging that Glassfish is using. This is because the component contains Log4J archive because one of the other components needs it. On the other hand Log4J is not creating the log file and so the log entries vanishes. Now I cannot remove Log4J because some of the components used needs it but I cannot make the commons logging to use the JDK logging in my component. Maybe I am just stupid enough not able to fix that but using a logging framework should not be rocket science. Right now I started to use System.out.println() just to see what is going on, ridiculous!

Now how to could this be fixed? Except the Glassfish community is striving to shut out any component that is using Log4J one should expect that Glassfish could provide a Log4J wrapper that takes the Log4J statements and redirects it to their JDK logging. As the JBI components show the issues from class loading making it impossible for Apache's Commons Logging to select the correct logging framework and even when only CL is used it may not work as expected.

This work is licensed under a Creative Commons License.