-
Notifications
You must be signed in to change notification settings - Fork 29
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
Reformat log statements so that they aren't susceptible to formatting errors and worse when {} are in the message #1084
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1084 +/- ##
============================================
+ Coverage 80.40% 80.59% +0.18%
+ Complexity 2944 2881 -63
============================================
Files 393 393
Lines 14536 14554 +18
Branches 1001 1000 -1
============================================
+ Hits 11688 11730 +42
+ Misses 2242 2220 -22
+ Partials 606 604 -2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
… errors and worse when {} could end up directly in the 'message' string. I tried to codify on a couple of standards as well. 1) setMessage(Supplier...) should not be used. Placeholders and arguments should always be used instead. 2) All arguments being added should use a supplier if the argument requires any evaluation of a function. To confirm, the regex `.addArgument\([^\(\)]+\([^\)]*` shouldn't found present. On stylistic levels 3) The sequence of fluent/builder operations should be setCause, setMessage, addArguments... 4) If more than one argument is added, each argument should be on a separate line, followed by a log() also on its own line. Signed-off-by: Greg Schohn <[email protected]>
8ebd9f8
to
99d5290
Compare
… in an earlier commit Signed-off-by: Greg Schohn <[email protected]>
+ "ms before trying again." | ||
) | ||
log.atInfo().setMessage("{}") | ||
.addArgument(() -> "After " + finalShardSetupAttemptNumber + "another process holds the lock" |
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.
let's change this to use constant string with argument insertion like the rest of the log lines
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.
done
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.
Please clean up the pr description and i'm good with this.
Updated logger usage in PredicateLoader.java and JsonTransformerTest.java to bring them up to speed with all the other logging calls Signed-off-by: Greg Schohn <[email protected]>
…to setMessage(FORMAT).addArgument...log(). Those left behind had either one argument or was clearer to leave as it was. Signed-off-by: Greg Schohn <[email protected]>
Signed-off-by: Greg Schohn <[email protected]> # Conflicts: # RFS/src/main/java/org/opensearch/migrations/bulkload/common/OpenSearchClient.java
Description
This converts and canonicalizes all of our existing log usage for all java projects. The rules followed are
() -> foo.get()
should be replaced withfoo:get
).See https://opensearch.atlassian.net/browse/MIGRATIONS-2161 for follow-up work to make these changes more durable.
Issues Resolved
Jira issue
Github Issue
Testing
gradle testing
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.