Parameterized logging jul #77
Conversation
… parameters get replaced with their actual values.
…cific which caused the unit test to fail on windows.
|
💚 CLA has been signed |
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
|
| public abstract void debug(String message); | ||
|
|
||
| public abstract void debug(String message, Object[] logParams); |
There was a problem hiding this comment.
Just an idea: may be a vararg so that callers can do debug("{} is not {}", 1, 2) vs debug("{} is not {}", new Object[]{1, 2})
| public abstract void debug(String message, Object[] logParams); | |
| public abstract void debug(String message, Object... logParams); |
There was a problem hiding this comment.
Yes I agree, I've refactored it to varargs.
What do you think of the place of the testSimpleParameterizedLog method? I was not sure about whether I should place the test in the abstract base class AbstractEcsLoggingTest (because testSimpleLog is also already there), or make a test in each formatter project.
There was a problem hiding this comment.
I really like the abstract way of handling this! IMO, the test classes in each formatted project should be as simple as possible and ideally only extend the abstract test and implement its abstract methods.
The java util logging formatter logged the following method call:
logger.log(Level.INFO, "test {0}", "test1"); as "test {0}" in the message field of the json body whereas "test test1" is the intended behaviour.
By using the super.formatMessage method from the JUL Formatter the parameters do get placed into the curly brackets.
I have also added a .replace("\r\n", "\n") in a unit test because the unit test does not work on windows because the line endings are different.