Description
When a system performs concurrent initialization of Camel, there's a good chance that it may lose messages due to log substitution behavior.
This is more likely to happen in tests (such as camel-quartz ones - highly concurrent) than in actual production code (though, it's still possible for some applications).
Nonetheless, this can cause a lot of confusion during debugging, as some log messages may not be present on the logs. The ones likely to be dropped on the logs are the ones called during build/initialization.
I think we can do 2 things to reduce the incidence of this problem:
- Delay the logger initialization in a few key places
- Add a note in the documentation, that the logging framework should be properly initialized before running Camel in highly concurrent scenarios