slf4j in favour of j.u.l. logging

[gmulders]

Dalesbred uses java.util.logging for logging. With this issue I'd like to request that it is converted to slf4j or some other thin implementable layer.

The one big advantage of java.util.logging is that it needs no external dependencies. However it is an implementation thus it forces the user of Dalesbred to use that specific logging library. Using the jul-to-slf4j bridge is no real option, since the impact on the performance is huge and the usage is pretty invasive.

Note that enhancement #23 might also open the door for enhanced query logging.

slf4j
Advantages:

• It's really small.
• Very common; lots of other libraries use it already so there is a good chance that the library is already on the classpath.
• Not an implementation; the user of the library can use whatever logging library he or she likes.
• It's API is nice and consistent (unlike j.u.l.'s ;-))

Disadvantage:

• It's an extra dependency.

Thin implementable layer
Advantages:

• No extra dependencies.
• To be implemented by the user, thus lots of freedom.

Disadvantage:

• Feels like reinventing the wheel.

[komu]

Yeah, I'm pretty much on the same page with you here. I use slf4j on all my projects and add jul-to-slf4j to bridge the logs. I do think that you overestimate the performance impact though: Dalesbred is pretty light on logging and generally the JDBC-calls will totally dominate the performance profile.

That said, I think I could be persuaded to switch to slf4j. In theory having extra dependencies is an annoyance, but in practice having to add jul-to-slf4j manually is even greater an annoyance. :)

A thin custom layer would actually be non-trivial to implement on top of slf4j because then slf4j would think the logging layer is the originator of log-messages, producing bad method info on logs.

[komu]

I finally released 1.2.0 with this change.