= New Logging API =
What does someone do if there is plenty of time? Create another logging framework? Frankly not. But what about improving what is there? What about changing things to the better?
There is JUL. There is log4j. There is commons-logging. And probably plenty of other stuff around.
Can someone imagine how many development time this logging discussions, decisions and migrations caused in the past years? Nobody. This is an approach to propose something new. To combine the best from all the things out there. To make up a solid logging approach for Java which would make most of us happy.
You're welcome to contribute.
= What is JUL? =
JUL is the common short-form of java.util.logging. This is the "Java Logging API" which is contained in the JDK. Via a logger you can save text to a central place to report on errors, provide additional information about your program, etc. This logging API allows to configure how messages are written by which class with which priority. It is described in detail in the [http://docs.oracle.com/javase/1.4.2/docs/api/java/util/logging/package-summary.html J2SE API Specification] . There is a [http://docs.oracle.com/javase/1.4.2/docs/guide/util/logging/overview.html Java Logging Overview] to introduce you to the basic workings.
It was initially specified with [http://jcp.org/en/jsr/detail?id=47 JSR 47]
= What are the shortcomings of JUL? =
* Logging should not be this much work!
* Log Levels ( ALL, SEVERE, WARNING, INFO, CONFIG, FINE, FINER, FINEST and OFF )
* API ( log(Level level, String message, Throwable exception) )
* configuration file located in JAVA_HOME/lib
* Missing [http://wiki.apache.org/logging-log4j/NDCvsMDC MDC / NDC]
* the root logger is shared in multi threaded environments / log messages from same class files from different webapp will go in the same log file in case of jdk logger. (unless you configuere handlers in code)
* JDK logger is not an interface / Lacking an abstract layer.
* only size based log file rotation
* time of localization of log-messages (call vs. rendering-time)
* you can only configure one instance of a given handler class. This means that you can log to just one file at a time
* No runtime configuration from within JUL
* lack of varargs for formatting
* configuration order of loggers matters (parent knows about child loggers)
* No handler inheritance (Global handlers)
* Missing standard handler (syslog, remote servers, jms, email)
* only property files for configuration
* weak error handling with RunTimeExceptions thrown