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.