Maulin,
Here is a table that I pulled out of a book that I am currently authoring.
Because of formatting issues, I am presenting them below as a List.
1. Simple Console, Socket, File Logging (JDK Logging - Yes, Log4J - Yes)
2. Multiple Log destination support � SysLog, NT Event Log, JMS Channel (JDK Logging - No, Log4J - Yes)
3. Comprehensive File rotation by date, size etc. (JDK Logging - No, Log4J - Yes)
4. Logging Format (Layout) Support (JDK Logging - No, Log4J - Yes)
5. Logging with Diagnostic Context (JDK Logging - No, Log4J - Yes)
6. Configuration Format (JDK Logging - Properties, Log4J - Properties, XML)
7. System property based Initialization (File or class as a system property) (JDK Logging - Yes, Log4J - Yes)
8. J2EE Affinity [By setting a system property, all the web applications in a JVM are affected. However, since you can bundle Log4J in your web application, it is local and change in configuration does not affect system wide) (JDK Logging - Less, Log4J - More)
9. JMX MBeans (JDK Logging - No, Log4J - Yes)
Apart from the pros you mentioned, 5, 8 and 9 are really what turns the table in favor of Log4J. No matter, how less (or more) logging you have, you need a Nested Diagnostic Context support. Otherwise logging from multiple users get mixed up.
J2EE affinity is very important when hosting multitude of departmental/enterprise apps on app server farms.
And then JMX Mbeans support to turn on/off logging in production environments is critical when you are in dire straits and seeing some critical error in production and want to turn on logging without stopping the app server.
Hope this helps. For more information: The chapter on logging in my book is almost ready. It will be posted for public review at
http://www.theserverside.com in a week.