> 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

Reply via email to