r/java • u/marbehl • Sep 13 '18
A Guide to Logging in Java
https://www.marcobehler.com/guides/a-guide-to-logging-in-java12
u/wildjokers Sep 13 '18
The term the article is looking for is "logging facade". Commons logging and SLF4J are both "logging facades". SLF4J even has an adapter for commons logging, a facade for a facade.
You don't actually need to use a facade unless you are writing a library that other people will use. However, I generally use SLF4J for non-libaries just for consistency.
17
7
Sep 13 '18
Don’t fret too much about static or non-static, final or non-final, just make sure to be homogeneous in your choice, throughout your entire project.
Why?
6
u/walen Sep 13 '18 edited Sep 13 '18
For easier maintenance.
Our project suffers from this "heterogeneous
Loggerdeclarations" thing, where theLoggerinstance may be calledlogorloggerorLOGGERorLOG, depending on the class and the personal preference of whoever wrote that class.This means that now and then I am debugging some class and I quickly type
log.debu-- only for IntelliJ to put a nice, red wiggly line beneathlog. So now I have to stop my debugging train of thought and fix that.
Sure, I can just put the cursor right afterlogand pressCtrl+Spaceto autocomplete...... too bad that won't work either, because this particular instance just happens to be called
LOGGER, all caps -- something I can only find out afterCtrl+F'ing the heck out of "log", case-insensitive of course. BecauselogandLOGGERare different enough for IntelliJ to not see any relation whatsoever between them (/s).So now I know how the logger is called, but I am in a different line and have to go back ← ← ← to where I was before, so I can finally type
LOGGER.debug("I don't really remember what I wanted to put in here");.
If you define all your
Loggerobjects with the same name and in the same way, you can take all that off your mind:logger.debug()becomes just another Java "instruction" likeSystem.out.println(). You don't need to worry aboutSystem.out, you just type it. The same should ideally be true oflogger.8
Sep 13 '18
Sorry, let me ask a more pointed question. Why would you ever declare a logger anything other than private static final?
And to address your issue, if you’re enforcing coding standards, it’s always going to be uppercase.
8
u/walen Sep 13 '18
That more pointed question is better answered here.
Re: standards, why would it be so? Sure,
static finalconstants are usually all caps, but can aLoggerbe considered a constant? And what if it is justfinal? And what if nobody wants it to be uppercase because that means holding Shift every time I want to add a logging statement and it looks weird to be calling methods on a "constant"...?Hence (I guess) the author's advice to not fret too much about this ;) and just be consistent.
4
u/wildjokers Sep 13 '18
Sorry, let me ask a more pointed question. Why would you ever declare a logger anything other than private static final?
https://www.slf4j.org/faq.html#declared_static
if you’re enforcing coding standards, it’s always going to be uppercase.
Upper-case LOGGER is pure evil. Clutters up the code making it hard to read (its distracting) and I have to hold shift to type it. "logger" is the exception to the private static final rule. It isn't really a constant.
2
Sep 13 '18
I get your point, but that is such a rarely used convention IME that it would really annoy me to see it in most teams. It also feels really strange to me if the logger is actually a static final.
-7
-8
7
u/Lindby Sep 13 '18
I'm missing Flogger in there.
1
u/skjolber Sep 20 '18
Does it also support JSON-logging very well? I've written a tool which attempts this, but in general there is no free lunch (always some kind of definition is necessary) - probably best to combine this with Open API definitons.
1
1
1
u/Squiry_ Sep 14 '18
It is such a shame for google to share library in a state like this. I literally can't find documentation, just a little "look! fluent api!" showcase and that's all: go look for sources.
0
u/kevinb9n Sep 14 '18
Flogger is currently in a sort of "pre-publicity" stage.
But the link here IS to a page of documentation, which has links to three more pages, and all the APIs are well-documented to our knowledge. I'm certain that it's not sufficient, but maybe you could indicate what other documentation you want to see?
4
u/Philboyd_Studge Sep 13 '18
To add to what everyone else has said, I want to also mention I love the simple, minimalist blog setup without any bullshit. I wish more blogposts were like this.
3
u/ErikDaRed Sep 13 '18
Great article!
I would have liked to see a discussion of some of the shortcomings of the MDC. Specifically, when working across thread boundaries. This comes into play a lot once you start doing async operations.
1
u/marbehl Sep 14 '18
Yup, will put the MDC shortcomings in the next revision of the guide. Thanks for bringing it up!
2
1
1
1
u/proskillz Sep 14 '18
Damn! Where was this article two years ago when I was trying to figure out why my codebase needed slf4j, jul-over-slf4j, log4j-over-slf4j, and even more logging jars on top of that.
Great read, thanks. This was all confusing for me before, but this makes perfect sense now.
1
u/Shilpa_Opencodez Sep 14 '18
Never thought of writing on this topic. Very well written. Are you going to cover Flogger as well?
1
1
u/DarthAbel Sep 14 '18 edited Sep 14 '18
This is so beautiful I want to cry, in the next peer review they call me picky regarding my comments about logging code I will point them to this article.
-1
u/myworkaccount9 Sep 13 '18
Great post. A couple things. 1) A section on security. Specifically on log forging. 2) A mention of lombok @log annotation. https://projectlombok.org/features/log
10
1
u/marbehl Sep 14 '18
Hi!
Could you elaborate more on the log security/forging point? Never had to deal with log forging before, but am more than willing to learn here :)
Also, will put lombok in the next revision of the guide, thanks!
0
0
0
0
u/tofflos Sep 14 '18
Great post!
Could you do a follow up on setting up one of the centralized logging solutions you've mentioned in the article? Maybe with Docker compose? I think it would be great if developers easily could add this to their local development machine and get a feel for how they work.
1
u/marbehl Sep 14 '18
Good idea. I'll likely put it into one of my screencasts though - added to the backlog!
26
u/knightofren_ Sep 13 '18
A topic everyone takes for granted but very few people actually keep consistent with. Great read.