Hi Erik,
Thank you for your message. In this case, Ross cross posted on slf4j-dev
and I has already provided an answer there. I repeat it here for the
convenience of the reader.
Catering for the eventuality of extra parameters would be relatively
complicated. More importantly, I think that it is not SLF4J's
responsibility to fix every possible error that could be made by the
programmer.
In addition, the fluent API allows adding key value pairs which should
avoid the pitfall described by Ross.
Best regards,
--
Ceki Gülcü
Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
On 02/02/2025 08:47, Erik van Oosten via slf4j-user wrote:
Hi Russ,
Mailing lists are not so popular anymore nowadays, chances that a sl4fj
developer will respond here are not so good. Probably the best thing to
do is write a feature request on https://github.com/qos-ch/slf4j/issues.
A pull request is probably be appreciated as well!
Kind regards,
Erik.
Op 25-01-2025 om 02:38 schreef Russ Block via slf4j-user:
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-user mailing list
slf4j-user@qos.ch
https://mailman.qos.ch/cgi-bin/mailman/listinfo/slf4j-user
--
Erik van Oosten
e.vanoos...@grons.nl
https://day-to-day-stuff.blogspot.com
_______________________________________________
slf4j-user mailing list
slf4j-user@qos.ch
https://mailman.qos.ch/cgi-bin/mailman/listinfo/slf4j-user
_______________________________________________
slf4j-user mailing list
slf4j-user@qos.ch
https://mailman.qos.ch/cgi-bin/mailman/listinfo/slf4j-user
