Closed dimalinux closed 11 years ago
I'm not convinced one way or another on this so feel free to discuss. I have the stacktrace in there so that you can see it when you are trying to figure out what went wrong. In some instances, that stack trace may be relevant to figuring out what went wrong (but only the engineer will know). For example, if later on the AuthenticationManager was null because Spring Security was unable to obtain an AuthenticationManager another way and your code required the AuthenticationManager you might want to see that stack trace.
I understand the problem better after trying to disable the message. My logging config was already weeding anything below "INFO" for "org.springframework.security". CGLIB is distorting who actually emitted the message. In order to get rid of the stack trace, you have to raise the log level of the config class that extends WebSecurityConfigurerAdapter.
This seems that part of the issue is that I am using getClass() for creating the logger. While this is quite common throughout Spring, I wonder if changing this to WebSecurityConfigurerAdapter.class would be sufficient. This would make disabling logging for that logger much easier. What are your thoughts? Does this seem like a reasonable compromise?
I like that solution. As it turns out, I never would have seen the stack trace if it hadn't been logged against one of my own classes. Thanks!
I made the logger change so closing. Thanks for bringing up this usability issue.
When extending WebSecurityConfigurerAdapter for an OpenID security configuration, the message below is expected behavior. Given that it's expected, at least in some cases, it would be nice if it didn't show the stack trace.
Feel free to reject this request. I'll just turn of debug logging for now.
The stack trace below is from the openid sample:
Thanks, Dmitry