Logging in Java: Another Slow Motion Explosion

DZone 's Guide to

Logging in Java: Another Slow Motion Explosion

· Java Zone ·
Free Resource

If someone said to you try and pick one aspect of the gigantic, hydra-like beast of Java that best typifies its current pathology, logging would probably be my choice. It‘s something that should be stupid simple, yet 15 years on, it‘s a buggered up mess with almost no feature progress for all the time and energy that‘s been expended. Logback has the ability to do replaces, e.g. “Here is my message and some field: {}”, theField, which is great. And on the whole, logback is great, I like it. But OMG, the amount of toil and trouble from this one little toenail of the beast is so out of proportion it makes the federal government look like a model of efficiency.

Most people setup some really basic config and then forget about it. Maybe they‘ll have their files roll automatically. And when they are debugging a problem, they will probably raise levels on certain packages, which is convenient and can aid in the process of discovering what is going on. But as usual on this platform, as soon as you step out of that you step into an underworld. We wanted to add an SMTP appender to a project last week. It was completely whackadoodle how much time it ended up taking. Gave me the opportunity to go through the logback documentation again. Here‘s what I want: all messages at level WARN to go to the SMTP appender and INFO to go to the console appender. How on earth can there be an ounce of complexity in that desire? Seriously. Well, there is. Why? Because, as usual, the model underlying the whole operation is stupid, and eventually, the solution is to game the system: either put a filter on one of the appenders or turn off ‘additivity.‘ This would make a classic, perfect example of what you get when ‘design‘ is not use case driven (which is 99% of the time in Java). One of the funniest things is I even downloaded the examples and the example for SMTP shows a single entry in the file. Yeah, I bet a ton of places only send log messages to email and don‘t record anything to console of file.

When I first started doing Objective C, I gasped at the stupidity of their logger. No levels. No configuration files, no nothing. Just send a message to it and look for your message in the console. Furthermore, the console window in Xcode is not detachable. Hani and Cedric ran down loggers in their otherwise really good book on testing. I live by them. Code needs to explain itself. How can you believe in readability (the code‘s power of static expression) and not believe in logging?? (the application‘s ability to express what it‘s doing and why)?

Then, I was reading around one day in the Xcode 4 docs and found them talking about log breakpoints. I thought about it for a few minutes and thought: ‘genius.‘ Unfortunately, I have not been able to get them to work (rare case of Apple being stupid) but the idea is awesome because I have seen over the years that a lot of times, you just need log information to solve something and makes so much more sense to just treat those cases and breakpoints. When I do have this, it will also remove the whole appeal of levels.

Meanwhile, I have been trying to get the JEE6 Weld archetype to run, and lo and behold, my current stopping point is a stupid logger error: the injector can't figure out who should provide the logger. (Isn't injection ambiguity one of the major fixes in CDI??)

Is this a platform, or is it really a sea of tinkerers just finding a little area to burrow in.. ?

With commons logging inow what a decade in the rear view mirror, it‘s safe to say we are past the dream of magical interop. I‘ll take the simple version that works, and that doesn‘t require a team to support it thanks.

Update: Found an article on the Apple site here that explains how to use logger breakpoints. I am pretty sure I didn‘t find this before when I was looking. Going to try to make this work again, this looks like it‘s pretty complete.


From http://www.jroller.com/robwilliams/entry/logging_in_java_another_slow


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}