@@ -152,14 +152,14 @@ Let's try to walk through the most common ones.
152
152
[#pitfal-toString]
153
153
==== Don't use `toString()`
154
154
155
- * [ ] `Object#toString()` is redundant in arguments
155
+ * [ ] Don't use `Object#toString()` in arguments, it is redundant!
156
156
+
157
157
[source,java]
158
158
----
159
159
/* BAD! */ LOGGER.info("userId: {}", userId.toString());
160
160
----
161
161
162
- * [x] Underlying message type and layout will deal with arguments
162
+ * [x] Underlying message type and layout will deal with arguments:
163
163
+
164
164
[source,java]
165
165
----
@@ -169,18 +169,15 @@ Let's try to walk through the most common ones.
169
169
[#pitfall-exception]
170
170
==== Pass exception as the last extra argument
171
171
172
- Using `Throwable#printStackTrace()` or `Throwable#getMessage()` while logging?
173
- Please, don't!
174
-
175
- * [ ] Don't call `Throwable#printStackTrace()`.
172
+ * [ ] Don't call `Throwable#printStackTrace()`!
176
173
This not only circumvents the logging, but can also leak sensitive information!
177
174
+
178
175
[source,java]
179
176
----
180
177
/* BAD! */ exception.printStackTrace();
181
178
----
182
179
183
- * [ ] Don't use `Throwable#getMessage()`.
180
+ * [ ] Don't use `Throwable#getMessage()`!
184
181
This prevents the log event from getting enriched with the exception.
185
182
+
186
183
[source,java]
@@ -189,14 +186,15 @@ This prevents the log event from getting enriched with the exception.
189
186
/* BAD! */ LOGGER.info("failed for user ID `{}`: {}", userId, exception.getMessage());
190
187
----
191
188
192
- * [ ] This bloats the log message with duplicate exception message
189
+ * [ ] Don't provide both `Throwable#getMessage()` and `Throwable` itself!
190
+ This bloats the log message with duplicate exception message.
193
191
+
194
192
[source,java]
195
193
----
196
194
/* BAD! */ LOGGER.info("failed for user ID `{}`: {}", userId, exception.getMessage(), exception);
197
195
----
198
196
199
- * [x] Pass exception as the last extra argument
197
+ * [x] Pass exception as the last extra argument:
200
198
+
201
199
[source,java]
202
200
----
@@ -209,8 +207,9 @@ This prevents the log event from getting enriched with the exception.
209
207
210
208
If you are using `String` concatenation while logging, you are doing something very wrong and dangerous!
211
209
212
- * [ ] Circumvents the handling of arguments by message type and layout.
213
- More importantly, this code is prone to attacks!
210
+ * [ ] Don't use `String` concatenation to format arguments!
211
+ This circumvents the handling of arguments by message type and layout.
212
+ More importantly, **this approach is prone to attacks!**
214
213
Imagine `userId` being provided by user with the following content:
215
214
`placeholders for non-existing args to trigger failure: {} {} \{dangerousLookup}`
216
215
+
@@ -253,7 +252,7 @@ Maven::
253
252
254
253
<dependency>
255
254
256
- <!-- The logging implementation (i.e., Log4j Core) -->
255
+ <!-- Logging implementation (Log4j Core) -->
257
256
<dependency>
258
257
<groupId>org.apache.logging.log4j</groupId>
259
258
<artifactId>log4j-core</artifactId>
@@ -449,7 +448,7 @@ Save the following XML document to `src/**test**/resources/log4j2-test.xml`:
449
448
== What is next?
450
449
451
450
Installation::
452
- While shared dependency management snippets should get you going, it can also be challenging depending on your use case .
451
+ While shared dependency management snippets should get you going, your case might necessitate a more intricate setup .
453
452
Are you dealing with a Spring Boot application?
454
453
Is it running in a Java EE container?
455
454
Do you need to take into account other logging APIs such as JUL, JPL, JCL, etc.?
0 commit comments