refactor(spark): use SLF4J parameterized logging instead of string concatenation#19184
Conversation
…ncatenation
Convert LOG string concatenation to {} placeholders in the hudi-spark
test classes TestHoodieClientMultiWriter and
TestDataValidationCheckForLogCompactionActions. Mechanical and
behavior-preserving.
hudi-agent
left a comment
There was a problem hiding this comment.
Thanks for working on this! This PR mechanically converts string-concatenation LOG calls to SLF4J {} parameterized logging in two hudi-spark test classes. I checked each conversion — the placeholder counts match their argument counts and the message content is preserved in every case, so the changes are behavior-preserving. No correctness issues found. A few style/readability suggestions in the inline comments. Please take a look, and this should be ready for a Hudi committer or PMC member to take it from here. A couple of small suggestions on the exception-logging pattern — passing e directly as the last SLF4J argument preserves the stack trace and keeps log messages fixed and searchable.
cc @yihua
Describe the issue this Pull Request addresses
A number of
LOGcalls in thehudi-sparktest classes build their message with+string concatenation. This eagerly builds the string even when the level is disabled and reads worse than a parameterized statement. This PR converts them to SLF4J{}templating. Part of the ongoing logging cleanup (follows #19155, #19156, #19157, #19158, #19159, #19160).Summary and Changelog
LOGcalls to{}placeholders in twohudi-sparktest classes (TestHoodieClientMultiWriter,TestDataValidationCheckForLogCompactionActions). Mechanical and behavior-preserving.Impact
none - test-only, purely mechanical logging change.
Risk Level
none
Documentation Update
none
Note: these classes use plain
LoggerFactory.getLoggerLOGfields. Migrating them to the Lombok@Slf4jannotation will be done in a separate round of cleanup sweeps; this PR only covers the concatenation-to-templating conversion.Contributor's checklist