This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Spring Security logging gripe

Apr 16th, 2011, 11:19 AM

Since source code locations are usually (or always, I don't have tijme to research and test) only available in log output files when a stack trace is logged and byte code has debugging symbols, it is extremely useful for log files to report the real Java Class in which the logging statement resides. The standard way to do this is to specify the logging category with the class that is currently executing when instantiating private loggers. Spring Security sometimes does this, but most often instantiates a protected logger using getClass(). That is very inconvenient and misleading because entries from either the logger-instantiating class or descendant logger-using classes will report the leaf runtime implementation class instead of the superclass in which the logging statement really resides. It really sucks to have to look through Spring Security source code just to find the real source of entries in my log files.

When I first saw this, I thought that it was probably to avoid discovery complications when custom or container class loaders are involved, but I think not because I see that some classes in Spring Security do it the right way (for example, LoginUrlAuthenticationEntryPoint). It is the same situation with the core module of Spring Framework-- some classes use protected Loggers with getClass() as category, and some use private loggers with static .class.

I understand that sharing loggers will be more efficient by not instantiating as many of them, but there are reasons (ask if you want details) why this efficiency gain is unwarranted and unnecessary in this case. The overriding goal for logging should be to log accurate details, and logging the source class as being some leaf-class whose code is not currently executing is inaccurate.

Note that Spring Framework's core module (at least) suffers from the same problem. I report the problem here because I happen to have a greater need for accurate logs from Spring Security classes.