Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[LOG] Some logs contains too long strings #84

Open
aurelien-baudet opened this issue Nov 7, 2019 · 0 comments
Open

[LOG] Some logs contains too long strings #84

aurelien-baudet opened this issue Nov 7, 2019 · 0 comments

Comments

@aurelien-baudet
Copy link
Member

aurelien-baudet commented Nov 7, 2019

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant