oscerd opened a new pull request, #25832: URL: https://github.com/apache/camel/pull/25832
Fixes [CAMEL-24454](https://issues.apache.org/jira/browse/CAMEL-24454). MllpComponent.logPhi defaulted to true, so message content reached the log at the default INFO/WARN levels with no configuration at all. For a protocol whose payload is patient data by definition, the safe default is the other way round. Two paths logged content regardless of the flag, because MllpSocketBuffer has no logPhi of its own: the partial-payload warning in readFrom(), which logs the content of a legitimate in-flight message from a slow sender rather than only unexpected bytes, and the bytes-before-START_OF_BLOCK warning in readSocketInputStream(). Both now go through a helper that honours the setting, printing <PHI suppressed> when it is off. The suppression is applied at the log statements, via a new Hl7Util.convertToLoggableString, rather than inside convertToPrintFriendlyString. That method is not a logging helper despite the name: generateAcknowledgementPayload() uses it to extract the MSH-9 field, so redacting inside it corrupts the acknowledgement rather than the log - which is what the MLLP suite showed when it was tried that way. Both methods now carry a javadoc saying so. LogPhiTest.testLogPhiDefault asserted that the default includes the payload; it now asserts the opposite. testLogPhiFalse and testLogPhiTrue are unchanged and still pass, so the flag still works in both directions - only the default moved. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Signed-off-by: Andrea Cosentino <[email protected]> \n## Verification\n\n9 files changed, including 1 test file(s). Module build with \`-am\` is green on current main, no generated-file drift. Verified against the pre-fix code when the change was written. _Claude Code on behalf of oscerd_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
