spring-projects
Log messages use concatenated strings
It seems that Spring.NET universally logs messages using string concatenation and interpolation instead of log formatting templates. This leads to problems when applications use structured logging in general, and in particular when raw message templates are logged.
For example, if we have an NLog layout (snippet) such as this:
{
"name": "message",
"layout": "${message}"
},
{
"name": "messageTemplate",
"layout": "${message:raw=true}"
}
A resulting log entry would be:
{
"time": "2025-03-17 15:55:21.5886",
"level": "DEBUG",
"logger": "Spring.Objects.Factory.Support.DefaultListableObjectFactory",
"message": "Invoking IObjectPostProcessors before initialization of object 'System.Data.OracleClient'",
"messageTemplate": "Invoking IObjectPostProcessors before initialization of object 'System.Data.OracleClient'"
}
instead of the expected:
{
"time": "2025-03-17 15:55:21.5886",
"level": "DEBUG",
"logger": "Spring.Objects.Factory.Support.DefaultListableObjectFactory",
"message": "Invoking IObjectPostProcessors before initialization of object 'System.Data.OracleClient'",
"messageTemplate": "Invoking IObjectPostProcessors before initialization of object '{name}'"
}
This makes template logging unusable for Spring logs (one reason to do this would be to easily categorize messages produces by a particular logging call), but, more importantly, could lead to unexpected sensitive data leakages (e.g. database connection string being logged unsanitized via the logged template because the client app does not expect actual values popping up here).
This could be quite the undertaking, but PRs are always welcome 👍🏻
I can imagine it would be quite some work to do. No promises, but would you be open to partial fixes? Maybe we (I'm writing on behalf of my workplace) could identify the most problematic spots and fix those if nothing else.
Partial is always better than nothing, logging fixes can be incremental. As Spring.NET currently uses Common.Logging, will that be a problem?
As Spring.NET currently uses Common.Logging, will that be a problem?
It's on my mind, but I'm not sure ATM, especially in our case as it's not really clear to me to what extent Common.Logging plays nice with NLog 5, it would need to be tested. We'll see what can be done.
I can take look how switching to Microsoft logging abstraction would work when I have the time, Common.Logging is generally a bit of a dead end.
@nzp main branch now uses MS logging abstractions for logging, so should be good to go for any logging template improvements. Might still be some rough edges and improvements needed though. LogManager.LoggerFactory is your entry point.
Awesome! Thank you very much for acting on this so quickly! We'll prepare a PR for the template issues, at least the ones that bother us most, as soon as possible.