Logging of SQL Params and Query when using JdbcTemplate [SPR-7782]

[spring-projects-issues]

Abhishek Gupta opened SPR-7782 and commented

In production applications it is imperative that SQL statements and bind parameters be logged at a configurable level for support purposes.

When using the JdbcTemplate spring does currently log both, but sql statements are logged at debug level and parameters are logged in the 'o.s.j.c.StatementCreatorUtils' class at trace level. It is impractical to keep trace level on in a critical (or any) production system - even for a single class. There are other non-important (or non-functional) debug/trace logs that might be in the class that are not required to be logged. Or new ones might be introduced in future versions.

We would want the query/params to be logged at info level but again that might not be suitable for others, so ideally it should be something that is configurable.

The work-around today is ugly, in that we wrap the JdbcTemplate just to be able to log the parameters. Ideally, if there could be a property in the JdbcTemplate that accepts the log level for functional logs (query, params in this case) it would be most helpful. Given that JdbcTemplate is now a total replacement for using any low level jdbc api, and is so popular, it makes sense to have this feature that will give users more control and contribute to the completeness of such a widely used Spring offering.

I am happy to use any other solution you might have that addresses this use-case.

Thanks,
Abhi

P.S. This really applies to other classes too like in the jdbc.object package

---

Affects: 3.0.5

Issue Links:

• JdbcTemplate parameter and result logging [SPR-9405] #14041 JdbcTemplate parameter and result logging ("is duplicated by")
• Revisit subsystem-oriented logging [SPR-8122] #12774 Revisit subsystem-oriented logging

6 votes, 14 watchers

[spring-projects-issues]

Chris Beams commented

This issue provides an excellent case-in-point for the larger goal of providing subsystem-oriented logging in the framework (#12774), allowing users to turn up and down logging categories aligned with areas of functionality in the framework as opposed to the current situation wherein all categories are based on fully-qualified classnames, which in many cases is too fine-grained. We'll tackle this particular issue for 3.2 M1, but with an eye on designing a general approach that can be applied elsewhere in the framework going forward.

[spring-projects-issues]

David Thexton commented

I like the idea of using subsystem-oriented logging (#12774) to address most of the concerns of this issue (which I'd discounted when looking at #14041 as I hadn't seen any prior evidence of the approach).

Perhaps not only loggers for the SQL query and SQL params, but also SQL results (complex results aren't currently logged)? And perhaps also variable levels of logging the same subsytem given the logging level? Specifically: SQL params verbosely at trace (as they are currently at StatementCreaterUtils) or less verbosely at debug (in a single line, as I proposed in PreparedStatementValueProvider in #14041) and SQL results verbosely at debug (as I proposed in PreparedStatementResultLogger in #14041) and simple results at info (as currently in JdbcTemplate) or less verbose (simple results only, as currently in JdbcTemplate).

If it's helpful for me to amend my previous attempt at #14041 I'm happy to.

[spring-projects-issues]

Chris Beams commented

Thanks, David. Will get back to you about this.

[spring-projects-issues]

Cemo Koc commented

Is it possible to port this fix to 3.2.x too?

[spring-projects-issues]

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.