I have gone with java.util.logging.

Hi Rob,
how about using SLF4J http://www.slf4j.org/index.html instead of the JDK logging? It serves a similar purpose as commons-logging without the class loader headaches.

It also provides a neat extension to formatting messages, that can save you lines of code http://www.slf4j.org/faq.html#logging_performance

Johan

Yes, worth considering... I'd like to hear more about why you think it worth moving from java.util.logging to something else though...

That is, java.util.logging is not perfect but I have found it reasonably good (for Ebeans needs) with the benefit of being standard and without ANY dependancies (on other code, more jars etc).

That is, I don't see java.util.logging as a solution for all logging problems (like transaction logging etc) but I do see it as a good approach for library/frameworks that will be embedded into a bigger system (like Ebean).

For me I see three issues/"pain" with java.util.logging.
1. Its simplistic design means it doesn't solve more complex logging problems well. I think the workarounds put in by Tomcat developers highlight this.
2. The default JDK implementations for handlers and formatters is pretty sad, especially for developers.
3. Setting of the configuration (logging.properties file) can be a pain if you have lots of small programs (having to specify the jvm -D argument all the time).

For 2 I have included some Handlers and Formatters in com.avaje.lib.log.
For 3 I have Ebean automatically load/configure logging when it starts up if you include a property in avaje.properties.

logging.properties.file=logging.properties

So, at the moment I am reasonable happy with the logging. (Daily rotating logs, separate avaje logging from application loggging, no avaje info logging to console for development).

Note: I had a quick look at slf4j ...

Well, I am happy with JDK logging too. However I am working on another open source project and I got requests about switching from JDK logging to commons logging. Which I rejected because of all the known class loader issues.

I just wanted to bring slf4j on the table in case other users are suggesting commons logging for ebean too...

So just stick with JDK logging for now fine with me :-)

The benefit of using slf4j logging over java logging is
1. You give the person who is installing ebean in a larger application (most likely every user) the ability to configure ebean logging with the same configuration that they configure the rest of their logging.
2. You remove from ebean the responsibility of programetically configuring the logger.

I realize that slf4j introduces a new dependency but it is a small one and one that may already have been introduced by some other component the application needs.