With this method or any similar method, public void info(String format,
Object... arguments) { if (isInfoEnabled()) {
handleArgArrayCall(Level.INFO, null, format, arguments); } }If the
number of objects in 'arguments' is more than the number of placeholders, {},
the extra argument objects are not logged. Is there a reason for that?
For example public void setTemperature(Integer temperature) { oldT = t;
t = temperature; //Sent three parameters log with two placeholders
//Output "Temperature set to 90. Old value was null." The word extra is not
printed logger.info("Temperature set to {}. Old value was {}.", t, oldT,
"extra"); if(temperature.intValue() > 50) { logger.info("Temperature
has risen above 50 degrees."); } }
If I get into a situation where I have sent more argument objects than
placeholders that it should append those un-placed arguments to the end of the
logged string. The intent of the developer is to have the parameter logged.
Finding this out from production is not good. What is sent to be logged is
important information, depending on the log level.
My use case is that I want to push some legacy code to start looking like SLF4J
so we can migrate away from the older pattern filled with isLogTraceEnabled
calls. I learned of the above when I was writing JUnit tests to see all the
things the code would do and not do.
I feel that https://www.slf4j.org/faq.html#logging_performance is telling me
that, in some way, the placeholder string substitution is faster than appending
multiple strings together. I understood the main point of the argument as
converting items to string before I needed them was where the overhead was.
Keeping them as type Object reduces that overhead.
I understand there are Sonarqube rules and PMD to prevent me from not having
the correct number of argument objects. This would help, but I feel like there
are still going to be misses. Since my code is custom, Sonarqube and PMD do
not feel like options.
_______________________________________________
slf4j-dev mailing list
slf4j-dev@qos.ch
https://mailman.qos.ch/cgi-bin/mailman/listinfo/slf4j-dev
