> Mark, > > On 11/8/19 11:54, Mark Thomas wrote: <snip/>
>> +1 but please use debug. Tomcat generally doesn't use trace. The >> expectation is that debug enables all logging. > > Really? I'm happy to use whatever you guys recommend, but this will do > things like: > > log.debug("Generating new CSRF nonce for session " + sessionId + ": > " nonceValue); > > ... > > log.debug("Evicting CSRF nonce for session " + sessionId + ": " + > nonceValue); > > ... > > log.debug("Rejecting request for " + requestURI + " to session " + > sessionId + " for invalid CSRF nonce: " + nonceValue); > > That's .... super chatty. I suppose you can always set the .level for > this class specifically. Indeed. "Super chatty" is consistent with how log levels are currently used. > In my own code, I tend to differentiate between trace and debug in > this way: > > 1. TRACE tells you everything that happens > 2. DEBUG tells you when something out of the ordinary happens > > In the above examples, TRACE would apply (using my policy) to the > "generating" and "evicting" messages, but DEBUG would apply when > logging the rejection of the request. We don't (currently) make the distinction in the Tomcat code. There might be a few places where trace is used but they are rare. Generally, the approach I tend to work to is if there is a (potential) bug for which you have a repeatable test case, enabling debug logging should be sufficient for you to work out what is going on. I guess it makes little different to me to set level to FINE or ALL so if you prefer to split debug() and trace() then I can live with that. But at this point I don;t see the need so I'll likely to continue to use debug(). Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org