> 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
