-
Notifications
You must be signed in to change notification settings - Fork 25.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce Log4j 2 #20235
Introduce Log4j 2 #20235
Changes from 4 commits
5a8f2d7
7da0cde
abf8a1a
0853fc8
9a58fc2
abe3efd
1f6a4be
4e69ac0
0fdc5ca
1d197ed
21dbc5b
ac8c2e9
e166459
487ffe8
750033d
07d1a72
76ab02e
c98e790
d9064f4
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -19,6 +19,8 @@ | |
|
||
package org.elasticsearch.action.admin.cluster.health; | ||
|
||
import org.apache.logging.log4j.message.ParameterizedMessage; | ||
import org.apache.logging.log4j.util.Supplier; | ||
import org.elasticsearch.action.ActionListener; | ||
import org.elasticsearch.action.support.ActionFilters; | ||
import org.elasticsearch.action.support.IndicesOptions; | ||
|
@@ -105,7 +107,7 @@ public void onNoLongerMaster(String source) { | |
|
||
@Override | ||
public void onFailure(String source, Exception e) { | ||
logger.error("unexpected failure during [{}]", e, source); | ||
logger.error((Supplier<?>) () -> new ParameterizedMessage("unexpected failure during [{}]", source), e); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I can't help but wonder if we shouldn't have a static helper function that does this for us? public static Supplier<ParameterizedMessage> message(String message, Object... params) {
return () -> new ParameterizedMessage(message, params);
} EDIT: forgot the It's of course another import, but it will probably be better than staring at There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Comment got erased by the last commit. I can't help but wonder if we shouldn't have a static helper function that does this for us? public static Supplier<ParameterizedMessage> message(String message, Object... params) {
return () -> new ParameterizedMessage(message, params);
} It's of course another import, but it will probably be better than staring at There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe, but then we would want to at least have a lot of extra overrides to avoid allocating a varargs array. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think that would be a lot cleaner than what it is here. It can probably be a secondary PR that happens in smaller waves though. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The problem is that these overrides would then introduce boxing on any primitive arguments, and that is something that we want to avoid as well. I do not think it's feasible to do this. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But that's not any different than the current non-exception logging? log4j just creates a ton of overloads with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
The whole point of going the
Yes. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Which boxing are you referring to? I'm not seeing what would be boxed here (that would not have already been boxed with the old code)? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @rjernst The proposal from @pickypg is for a method public static Supplier<ParameterizedMessage> message(String message, Object... params) {
return () -> new ParameterizedMessage(message, params);
} This will cause an allocation of an public static Supplier<ParameterizedMessage> message(String message, Object p1, Object p2) {
return () -> new ParameterizedMessage(message, params);
} removes the These allocations/boxing will occur regardless of whether or not the log level is fine enough to emit the corresponding log message. With the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
But this would have been the case with the old methods as well (so nothing would be changing). Having to do the cast makes logging a pain to use parameterized messages. While creatinga bunch of overloaded helpers may be a pain, maybe it is worth it. Or maybe having this pain will lead us to not depend on logging so much, so it could be good. :) I could go either way. |
||
listener.onFailure(e); | ||
} | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you at least add a comment with this linking to a followup issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I opened #20243 and pushed 4e69ac0.