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.