When debug level is enabled, messages and response bodies are logged. In some cases (when images are inlined using base64 strategy for example) the log is too heavy. Debugging the message content can be useful. Here are the possible solutions:
Do not log messages, bodies or anything that can be heavy
- loose useful information when debugging or testing
Use trace level
- not really a great improvement
Use an utility method for possible heavy objects
+ easy to integrate
+ heavy object could be written somewhere else and log message could contain the path to the object
- need to search for all possible heavy objects (depends on toString method)
- need to think about it every time
- some objects doesn't seem to be heavy but could be in some cases (like a message when unsing base64 image inlining) so it could be easily forgotten
Use an "interceptor"
+ decouple logging needs for developer and performance
+ heavy object could be written somewhere else and log message could contain the path to the object
- not really easy to integrate
- may interfere with end-user application or Spring Boot
Use a custom LOG facade
+ easy to integrate
- adds another facade to logging systems
- need to update references everywhere
- need to implement the whole facade
Use another approach to logging: instead of explicitly use logging, emit events
+ totally decouple logging needs
+ events can also be used for anything else (marketing needs)
+ logs are centralized so update is easier
+ less technical code everywhere
+ error handling could be improved
- some events may just be there for logging and be strange to be present in code
- log "context" is lost (no LoggerFactory.getLogger(class)) => need to pass explicitly the context
- when there is an issue, we have to find where the log has been written and where is the original source
- using a single class for logging using explicit method names (Event.sendingMessage(), Event.messageSent()) would lead to a big class
- using a class per event may lead to too many classes (Event.publish(new SendingMessageEvent()), Event.publish(new MessageSentEvent())
- using an interface need to inject in every existing class
When debug level is enabled, messages and response bodies are logged. In some cases (when images are inlined using base64 strategy for example) the log is too heavy. Debugging the message content can be useful. Here are the possible solutions:
-loose useful information when debugging or testing-not really a great improvement+easy to integrate+heavy object could be written somewhere else and log message could contain the path to the object-need to search for all possible heavy objects (depends on toString method)-need to think about it every time-some objects doesn't seem to be heavy but could be in some cases (like a message when unsing base64 image inlining) so it could be easily forgotten+decouple logging needs for developer and performance+heavy object could be written somewhere else and log message could contain the path to the object-not really easy to integrate-may interfere with end-user application or Spring Boot+easy to integrate-adds another facade to logging systems-need to update references everywhere-need to implement the whole facade+totally decouple logging needs+events can also be used for anything else (marketing needs)+logs are centralized so update is easier+less technical code everywhere+error handling could be improved-some events may just be there for logging and be strange to be present in code-log "context" is lost (no LoggerFactory.getLogger(class)) => need to pass explicitly the context-when there is an issue, we have to find where the log has been written and where is the original source-using a single class for logging using explicit method names (Event.sendingMessage(), Event.messageSent()) would lead to a big class-using a class per event may lead to too many classes (Event.publish(new SendingMessageEvent()), Event.publish(new MessageSentEvent())-using an interface need to inject in every existing class