Getting Tomcat internal logging working

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Getting Tomcat internal logging working

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

All,

I can't believe I'm having trouble with this, but I'm struggling with
enabling logging.

I'm experimenting with the CsrfPreventionFilter, which currently has
zero logging at all in it. So, first I modified the code to add:

+     private final Log log =
LogFactory.getLog(CsrfPreventionFilter.class);

and, later

        if (nonceCache == null || previousNonce == null ||
                !nonceCache.contains(previousNonce)) {
+           log.trace("nonceCache=" + (null == nonceCache ? "(null)" :
nonceCache.cache));
+           log.trace("previousNonce=" + previousNonce);
+           log.trace("nonceCache.contains=" + (null == nonceCache ?
"(null)" : nonceCache.contains(previousNonce)));

            res.sendError(getDenyStatus());
            return;
        }

Finally, I modified these lines in $CATALINA_BASE/conf/logging.propertie
s:

- - java.util.logging.ConsoleHandler.level = FINE
+ java.util.logging.ConsoleHandler.level = ALL

...

+ org.apache.catalina.filters.level=ALL

When running, I see no logging when I'm expecting to see things in
catalina.out. I changed these lines from log.trace() to
System.err.println() and they do indeed show up.

What am I missing?

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3DhQoACgkQHPApP6U8
pFh9WQ/+P6GkuDL9YVWq2+Uv++e8dCgYSGo1hNr+1olun5+LzkWl9y4hfRpineVV
R4KHaeEoq24VJZWN8PmzZRZnkETLnATGZ82vTzVDJi+pfbxn+bC4e3wCRedUb6p1
Ieoro6II5p/621aQkClMQMht/ruu2PpEHx7qPjYa77x+fl4crDCq4cJ8fLeACUGZ
tTKnEZYqw/vE6eUozLE/KDYVSRmsvzE6PZ7Rk8Duv8k2dFHovwXoTkvPxZ8o8q/v
lWl20iPIsy+8otWbWx+/9fmm8LnPmD3cd1FhaczL86omOp1VYfMFW9KsMQMcZTaw
4jVkb9uJva1eupJu4CoNCecCRiOK0/RznkuA4wO210TqUC4pzSoZHQVIzM+oO9J0
JYrbR3dqmKXaBrSB7vGt2SnooD4QJPRTVGpYRmt8Xe42uXrZ1OPawb7fnOZntjQg
MvvFZa4QcUv69jBntfaopiMFLU+PcQMH6xVLw8dy1EGRAcEzD+FnVhNpir82NdXD
ZcVUGeUZrt+rw6+MLr6i8Due0hd5WYaaggH/obDle9lgaySB81jSsZTKwqTBo4Tv
KFKuL5NTKnQ/3vsWngRW/KuX50LDVXdY3Uhs0ZDKeUj/nQipc16s//KH4E7jaSsh
opaJDbUL+WU9tP/EWTmxTUptaNO6wz6do/QDIfEGk2RePvWSjpA=
=Psm0
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Getting Tomcat internal logging working

Konstantin Kolinko
чт, 7 нояб. 2019 г. в 05:44, Christopher Schultz <[hidden email]>:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> All,
>
> I can't believe I'm having trouble with this, but I'm struggling with
> enabling logging.
>
> I'm experimenting with the CsrfPreventionFilter, which currently has
> zero logging at all in it. So, first I modified the code to add:
>
> +     private final Log log =
> LogFactory.getLog(CsrfPreventionFilter.class);
>
> and, later
>
>         if (nonceCache == null || previousNonce == null ||
>                 !nonceCache.contains(previousNonce)) {
> +           log.trace("nonceCache=" + (null == nonceCache ? "(null)" :
> nonceCache.cache));
> +           log.trace("previousNonce=" + previousNonce);
> +           log.trace("nonceCache.contains=" + (null == nonceCache ?
> "(null)" : nonceCache.contains(previousNonce)));
>
>             res.sendError(getDenyStatus());
>             return;
>         }

Are you modifying the correct file?
(1. At build time it is copied to the output directory. Are you
modifying the source or the copy?

2. The configuration file is enabled via
-Djava.util.logging.config.file= system property that is set by
catalina script.  If you run Tomcat in some other way, that system
property may be not set at all. (E.g. when running Tomcat from within
Eclipse IDE.)
)

> Finally, I modified these lines in $CATALINA_BASE/conf/logging.propertie
> s:

> - - java.util.logging.ConsoleHandler.level = FINE
> + java.util.logging.ConsoleHandler.level = ALL
>
> ...
>
> + org.apache.catalina.filters.level=ALL

Looks OK.  Personally I never use 'ALL', but it should be OK. I prefer
to use FINE, FINER or FINEST.

https://docs.oracle.com/javase/7/docs/api/java/util/logging/Level.html#ALL

> When running, I see no logging when I'm expecting to see things in
> catalina.out. I changed these lines from log.trace() to
> System.err.println() and they do indeed show up.
>
> What am I missing?
>

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Getting Tomcat internal logging working

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Konstantin,

On 11/7/19 00:02, Konstantin Kolinko wrote:

> чт, 7 нояб. 2019 г. в 05:44, Christopher Schultz
> <[hidden email]>:
>>
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>> All,
>>
>> I can't believe I'm having trouble with this, but I'm struggling
>> with enabling logging.
>>
>> I'm experimenting with the CsrfPreventionFilter, which currently
>> has zero logging at all in it. So, first I modified the code to
>> add:
>>
>> +     private final Log log =
>> LogFactory.getLog(CsrfPreventionFilter.class);
>>
>> and, later
>>
>> if (nonceCache == null || previousNonce == null ||
>> !nonceCache.contains(previousNonce)) { +
>> log.trace("nonceCache=" + (null == nonceCache ? "(null)" :
>> nonceCache.cache)); +           log.trace("previousNonce=" +
>> previousNonce); +           log.trace("nonceCache.contains=" +
>> (null == nonceCache ? "(null)" :
>> nonceCache.contains(previousNonce)));
>>
>> res.sendError(getDenyStatus()); return; }
>
> Are you modifying the correct file? (1. At build time it is copied
> to the output directory. Are you modifying the source or the copy?

Yes. As I said, when using System.err.println() instead log
log.trace(), I do get logging (to stderr).

> 2. The configuration file is enabled via
> -Djava.util.logging.config.file= system property that is set by
> catalina script.  If you run Tomcat in some other way, that system
> property may be not set at all. (E.g. when running Tomcat from
> within Eclipse IDE.) )

I'm using bin/catalina.sh start to launch Tomcat on Macos. The 'ps'
command shows the following partial command-line:

[...]
- -Djava.util.logging.config.file=${CATALINA_BASE}/conf/logging.properties
- -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager [...]

The file ${CATALINA_BASE}/conf/logging.properties does indeed have the
changes below.

>> Finally, I modified these lines in
>> $CATALINA_BASE/conf/logging.propertie s:
>
>> - - java.util.logging.ConsoleHandler.level = FINE +
>> java.util.logging.ConsoleHandler.level = ALL
>>
>> ...
>>
>> + org.apache.catalina.filters.level=ALL
>
> Looks OK.  Personally I never use 'ALL', but it should be OK. I
> prefer to use FINE, FINER or FINEST.

I did that in desparation after FINEST wasn't getting the job done.

> https://docs.oracle.com/javase/7/docs/api/java/util/logging/Level.html
#ALL
>
>
>> When running, I see no logging when I'm expecting to see things
>> in catalina.out. I changed these lines from log.trace() to
>> System.err.println() and they do indeed show up.
>>
>> What am I missing?

So... what else should I check?

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3EJeAACgkQHPApP6U8
pFj2ABAAjtESHJSSUFIaoNzrC6bJQTCOMYCMfxAV7s7Kz4/L/Be1NCQo7IAeLnj2
TIvW78j8IX7EUZ9iFu16kJS+JU5Fpukug4gUtj2BRyh3g/PyLg7dVD98pAyaQ9dK
qsomH7HUBCUhU+dw0ibT4PxtH7d2DZ5sM/iZmhk6IVsCBgfCwzP353NEpOTRnr1B
VnXOM1LGSHmttJpUiiNFrN8Yz490Q4N4g+YOaA0jR33m2WokZl3kB82PH+sWcfPI
TCD/vj90u0MFcprR8WpR5dz2z5pfnhFdSluY8nbqUWciwI0xfcGy0HcI1kbw5Kcz
plUdWi7O4nYT1EcDKQO6F/NdJlSMQ9EC70DUdTinblz2Bih4KbF9OQY4lMMw/Ha8
c/3OVv7TDRes94DoNjT/wDgNROy5mm57CI+HTpsoWoYDSObJcwLYAEQJc00vMEq9
pMuBxcI8B4D9S6QiepLWNVggwGjJ/Q6ax2hqBCS3aElI+limL5mQyW57Z9snwN0V
WwxwGOoX0KUa6YnYRL3UVN9q6X0CHDT5hBF5x0+aMWjjrzQRaOKpaOI8yKOGFWmr
ijZuwkDiR4die2mt7OtFydsTDLcCdkUFQGMqFxS01glB0RIX7yy1ITHkwdfI6qnj
RoteOJh9HZ41/GFd2uQFHP52W3hKtMzXfHaK4chBWIbyyVtpkh4=
=shca
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Getting Tomcat internal logging working

Konstantin Kolinko
чт, 7 нояб. 2019 г. в 17:11, Christopher Schultz <[hidden email]>:

>
> I'm using bin/catalina.sh start to launch Tomcat on Macos. The 'ps'
> command shows the following partial command-line:
>
> [...]
> - -Djava.util.logging.config.file=${CATALINA_BASE}/conf/logging.properties
> - -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager [...]
>
> The file ${CATALINA_BASE}/conf/logging.properties does indeed have the
> changes below.

OK, good.

(I hope that `ps` shows the actual path to logging.properties. There
should not be unexpanded reference to a environment variable above.)

This reminds me: ClassLoaderLogManager allows each web application to
have its own configuration of logging. If you have a
"logging.properties" file elsewhere in classpath of that web
application, it will have precedence over the default one.

The recommended use of this technology is to place your configuration
into WEB-INF/classes/logging.properties file of your web application.

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Getting Tomcat internal logging working

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Konstantin,

On 11/7/19 15:20, Konstantin Kolinko wrote:
> чт, 7 нояб. 2019 г. в 17:11, Christopher Schultz
> <[hidden email]>:
>>
>> I'm using bin/catalina.sh start to launch Tomcat on Macos. The
>> 'ps' command shows the following partial command-line:
>>
>> [...] -
>> -Djava.util.logging.config.file=${CATALINA_BASE}/conf/logging.propert
ies
>>
>>
- - -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager [...
]
>>
>> The file ${CATALINA_BASE}/conf/logging.properties does indeed
>> have the changes below.
>
> OK, good.
>
> (I hope that `ps` shows the actual path to logging.properties.
> There should not be unexpanded reference to a environment variable
> above.)

Yep. I hand-edited that to shorten the real path.

> This reminds me: ClassLoaderLogManager allows each web application
> to have its own configuration of logging. If you have a
> "logging.properties" file elsewhere in classpath of that web
> application, it will have precedence over the default one.
>
> The recommended use of this technology is to place your
> configuration into WEB-INF/classes/logging.properties file of your
> web application.

My web application DOES have a WEB-INF/classes/logging.properties and
it does indeed say nothing about the CsrfPreventionFilter.

Since the TCCL is the WebappClassloader during execution of the Filter
(it's defined in my app's WEB-INF/web.xml file), it must be using the
application's logging.properties and not the global one.

This makes sense and is a little irritating to me, but definitely
fixable. I'll double-check that this is the case, shortly.

I think I'm going to commit my trace logging to CsrfPreventionFilter
because I find it helpful to see what's happening in there when trying
to deploy CSRF protections. Not being able to see what the class was
doing made it hard to figure out what was wrong. In my case, the
problem was that my nonce cache wasn't large enough, and hitting my
login page caused more than the default=5 nonces to be generated,
evicting the first nonce created -- the one which was added to the
<form action> for logging-in. So I couldn't even login to my own
application :)

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3FfU4ACgkQHPApP6U8
pFgrHA/+NPGf9qhPgIlLpd8tO7k0L7FjA9P4R6zKYhE7dAj5PuVHfotHxnWbqJBl
u8wiAem65Va4h6hPqjxS6h8dHz1YGJicukBgkjh1WgywU38W4Bp8HiK3np0OjX/o
QFD1RD2jE3h6/J4bdrtXgt3o9ht3UXR9pdNKfzsaarI7AwLdg7gM+ty8QmAah6Mv
eHvKzPf8D6moyJlsqDkIADV+FQFU+O+2pDUnoEnrk0fDI+0X332nR6hg4XE/Os94
izKb4TXS5wJUa0Ja5y0tkCnHTvBuW8gdP/yFZEnaXdeGIpv9+vAWxFIwos9ByR74
XRJpoNo7BTsB18v7EZmZ8cd8CzeU6+tisP2LpLN+m0asXlpQopJTARCjEYBiPKWB
4RLKyNwhbw+vSD9XebBa1YG2WUVAi06WAeqGVSGBV75ZLOHEiJP3qSv996XfCSwQ
47E9qECX0rYn+0FlEtrdqIZuFcp82kjCBUpEiYfSRETnBblXPX31h4aAgeXQooW/
4J5Gr89ibb1nXmEIsM9SijhAghvU0JZ0NCrtBH2SIeGLztL/STr9Eg1jFmT/F1vI
TcHbA1gy73PLH6YOGw9f/QpjEbtNIs8E50S4vez0r2bI5DO5WB+b1MlpzXbHc7/G
PGjma2w00MLW1X97N/9XWvwEbp7Gn3JXMkk5bfa4oCeuat3G8EE=
=NRa6
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Getting Tomcat internal logging working

markt
> Konstantin,
>
> On 11/7/19 15:20, Konstantin Kolinko wrote:
>> чт, 7 нояб. 2019 г. в 17:11, Christopher Schultz
>> <[hidden email]>:
>>>
>>> I'm using bin/catalina.sh start to launch Tomcat on Macos. The
>>> 'ps' command shows the following partial command-line:
>>>
>>> [...] -
>>> -Djava.util.logging.config.file=${CATALINA_BASE}/conf/logging.propert
> ies
>>>
>>>
> - -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager [...
> ]
>>>
>>> The file ${CATALINA_BASE}/conf/logging.properties does indeed
>>> have the changes below.
>
>> OK, good.
>
>> (I hope that `ps` shows the actual path to logging.properties.
>> There should not be unexpanded reference to a environment variable
>> above.)
>
> Yep. I hand-edited that to shorten the real path.
>
>> This reminds me: ClassLoaderLogManager allows each web application
>> to have its own configuration of logging. If you have a
>> "logging.properties" file elsewhere in classpath of that web
>> application, it will have precedence over the default one.
>
>> The recommended use of this technology is to place your
>> configuration into WEB-INF/classes/logging.properties file of your
>> web application.
>
> My web application DOES have a WEB-INF/classes/logging.properties and
> it does indeed say nothing about the CsrfPreventionFilter.
>
> Since the TCCL is the WebappClassloader during execution of the Filter
> (it's defined in my app's WEB-INF/web.xml file), it must be using the
> application's logging.properties and not the global one.
>
> This makes sense and is a little irritating to me, but definitely
> fixable. I'll double-check that this is the case, shortly.
>
> I think I'm going to commit my trace logging to CsrfPreventionFilter
> because I find it helpful to see what's happening in there when trying
> to deploy CSRF protections.

+1 but please use debug. Tomcat generally doesn't use trace. The
expectation is that debug enables all logging.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Getting Tomcat internal logging working

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mark,

On 11/8/19 11:54, Mark Thomas wrote:

>> Konstantin,
>>
>> On 11/7/19 15:20, Konstantin Kolinko wrote:
>>> чт, 7 нояб. 2019 г. в 17:11, Christopher Schultz
>>> <[hidden email]>:
>>>>
>>>> I'm using bin/catalina.sh start to launch Tomcat on Macos.
>>>> The 'ps' command shows the following partial command-line:
>>>>
>>>> [...] -
>>>> -Djava.util.logging.config.file=${CATALINA_BASE}/conf/logging.prope
rt
>>
>>>>
ies

>>>>
>>>>
>> -
>> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
>> [... ]
>>>>
>>>> The file ${CATALINA_BASE}/conf/logging.properties does
>>>> indeed have the changes below.
>>
>>> OK, good.
>>
>>> (I hope that `ps` shows the actual path to logging.properties.
>>> There should not be unexpanded reference to a environment
>>> variable above.)
>>
>> Yep. I hand-edited that to shorten the real path.
>>
>>> This reminds me: ClassLoaderLogManager allows each web
>>> application to have its own configuration of logging. If you
>>> have a "logging.properties" file elsewhere in classpath of that
>>> web application, it will have precedence over the default one.
>>
>>> The recommended use of this technology is to place your
>>> configuration into WEB-INF/classes/logging.properties file of
>>> your web application.
>>
>> My web application DOES have a WEB-INF/classes/logging.properties
>> and it does indeed say nothing about the CsrfPreventionFilter.
>>
>> Since the TCCL is the WebappClassloader during execution of the
>> Filter (it's defined in my app's WEB-INF/web.xml file), it must
>> be using the application's logging.properties and not the global
>> one.
>>
>> This makes sense and is a little irritating to me, but
>> definitely fixable. I'll double-check that this is the case,
>> shortly.
>>
>> I think I'm going to commit my trace logging to
>> CsrfPreventionFilter because I find it helpful to see what's
>> happening in there when trying to deploy CSRF protections.
>
> +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.

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.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3FpQoACgkQHPApP6U8
pFjt6A/+MtAJyh6pLcigwvfqMVOsoQ1MH7Lq+I/X1xR6ScfTds2UBNRV1iGBr2gw
KjqC5eX+oIpmNo4ON0Vh53VgskKplwGR6bio2Jexy7f9HEf7j/4gW73GQBV8Fm0/
CtiIg3zjCLAYlXYnslt6vdc1X6GlxwtRvFI/TXAzwSWUY+FJpfvZHx2M+6kTV6zW
qFKtDzryvh2jNmwFjrkiJsMuLgCthWKCRHFVxImqc1RG5e8hRQbZ5hUm9WUXu0dH
3Y+ZdFHT+yVJxPS4RBtursic8g25PI9Sg1tI/W77ewP+SY9V8i1LNJwVK/GkSh8w
yhc2Dol/bIGGLNsxY9IjgwbdQyeTfXXJ5b6wm0pG5tLI+D0trVUX7CxBHi6XenSb
kRYKPjWbAwV+Ss7eZNBu5jei4DvF3V8m2oUXxBNAipSV8T8Z1G29/b137146feqq
Y4Tsz8Rodmks4k+o8neYDI2CQ+sN9JYFhKsKxlKFrVh/vvaCBxPL6rpJarCUUSKe
LKDkT/HsjZxvAKLpDqnJuILxsoxrKKg+KdsjMu7SSZ4kPmAGdW5EFRwPhsdaXmxn
3ITJyGtNSKCGBTC6bZI1FjKmstwTFEKCJHQVcAD26wnfMbmc7zyta2uH3OLIatSt
dw+iOOkKg9zGU3icvpB6bHwhrn2B/QNWDq03TzdUu+ts18PU5NY=
=Q/4i
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Getting Tomcat internal logging working

Christopher Schultz-2
In reply to this post by Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Konstantin,

On 11/8/19 09:35, Christopher Schultz wrote:

> On 11/7/19 15:20, Konstantin Kolinko wrote:
>> This reminds me: ClassLoaderLogManager allows each web
>> application to have its own configuration of logging. If you have
>> a "logging.properties" file elsewhere in classpath of that web
>> application, it will have precedence over the default one.
>
>> The recommended use of this technology is to place your
>> configuration into WEB-INF/classes/logging.properties file of
>> your web application.
>
> My web application DOES have a WEB-INF/classes/logging.properties
> and it does indeed say nothing about the CsrfPreventionFilter.
>
> [snip]
>
> This makes sense and is a little irritating to me, but definitely
> fixable. I'll double-check that this is the case, shortly.

Confirmed: it was my application's WEB-INF/classes/logging.properties
file which was taking precedence, here.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3F5SIACgkQHPApP6U8
pFhHeg/+OQ5g1V3B51Mna2jQfXYgW5sEfTrEdH6UCStarIaGykEyE8phwPNBxxtl
RkGCE3imiaX0LoJ6NXDtRuVs4l07CAlN1M4LE5THSNk1O1kJIpIG5BvZMqkJyH3D
9pw7j8C8Pze4MwyvP71txUf+VeGSaud89h+azEzgFhtJlCPcozY1rxwnDB6ZHq3P
SCYO5DXfgOOcP4CLxpLL2JuZ5AFadQZaBnUZYjZ1W08Dvu6A9vx6/pP2gNsvq4WE
d53H7BHkUxL28kwZcr0PG5KvLlDTz5qP/0oW8Dus5xesdXnVxkzS/QKxpv6N3M+s
x6Zhz34fIqWYQQusacnNzqxCDMvfaaaGD9I9yaJaJDpL1Ib0ulIndQJxvzFRrNl8
3EUu3NUfq2K1xlWDzCYrKefclGLOqj2ZNqFs8Zgbu/ehahuaSYRHb67Pvl4IzDwM
P0+J2ECsbqquysRoqvb3HX2KXVrOI3GWDyjLLZgFZJD/OnqCG95l0MfEpTrafOEV
E7EXNPuvjn0FrL5+DBsL8s1U26ND616LGI2uFwIYdEfU6tfsMqcu7t0h1Evdgggx
HlYN24dcU5Bqy+lMT9uQPaw5c3oxoZ1MDLT0Bhop380SUJGMVnrTUKJVF8ZQt6An
0U5+GZKJIHFyzlyjqpjCBIzCtzEcf04VKbF9eCdMs9psot6uA9w=
=fTDq
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Getting Tomcat internal logging working

markt
In reply to this post by Christopher Schultz-2
> 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: [hidden email]
For additional commands, e-mail: [hidden email]