Re: Struggling to get trace/debug logging from Tomcat components

2025-03-14 Thread Konstantin Kolinko
чт, 13 мар. 2025 г. в 20:37, Christopher Schultz :
>
> Konstantin,
>
> On 3/13/25 12:34 PM, Christopher Schultz wrote:
> > Konstantin,
> >
> > On 3/13/25 10:55 AM, Konstantin Kolinko wrote:
> >> чт, 13 мар. 2025 г. в 16:42, Christopher Schultz
> >> :
> >>>
> >>> All,
> >>>
> >>> I really should be able to figure this out for myself but I'm frustrated
> >>> and might just need someone to show me that I'm spelling something
> >>> wrong.
> >>>
> >>> I'm trying to get all logs from the CsrfPReventionFilter. I know it's
> >>> working because I get 403 responses when it's enabled and don't get them
> >>> when it's not. But it's 100% silent and I'm getting no logs.
> >>>
> >>> I've added this to the bottom of the stock conf/logging.properties file:
> >>>
> >>> org.apache.catalina.filters.CsrfPreventionFilter.level = ALL
> >>> org.apache.catalina.filters.CsrfPreventionFilter.handlers =
> >>> java.util.logging.ConsoleHandler
> >>>
> >>> I shouldn't need the second line, since the default .handlers is
> >>> ConsoleHandler and the async handler for catalina.[date].
> >>>
> >>> I'm not seeing anything more detailed than INFO in catalina.out or
> >>> catalina.[date]. But...
> >>>
> >>> 1catalina.org.apache.juli.AsyncFileHandler.level = ALL
> >>> ...
> >>> java.util.logging.ConsoleHandler.level = ALL
> >>>
> >>>
> >>> ??!
> >>>
> >>> This is Tomcat 9.0.98 on Linux with a stock conf/logging.properties file
> >>> (plus my .level=ALL for this filter)
> >>>
> >>> What am I missing?
> >>
> >> 1. It may be that your web application has its own logging.properties
> >> file in classpath,
> >> thus it is preferred over the default one.
> >
> > There is a logging.properties in my application's webapps/WEB-INF/
> > classes/logging.properties file but I wouldn't expect that to interfere
> > with Tomcat's logging.
> >
> >> One option to prevent such behaviour is to reconfigure Tomcat to use the
> >> java.util.logging.LogManager from JRE instead of its own class.
> >
> > I will try that if I get desperate. :)
> >
> [...]
>
> Switching to the JDK's LogManager worked.
.
Logging configuration comes from TCCL

CsrfPreventionFilter is a Filter. A Filter belongs to a web
application (unlike a Valve that may belong to a Host and in that case
will be shared). Thus logging for that filter may be configured
separately per web application. The "log" field in
CsrfPreventionFilter is intentionally an instance field, not a static
field.

How the global logging configuration affects a web application that
has its own configuration is a question of how those two
configurations are combined. The global configuration is essentially
ignored. To be specific, looking at the source code:

(1) Looking at ClassLoaderLogManager#findProperty(),
if a logging configuration is present then properties are only read
from the local configuration, (and parent configuration is ignored).

(2) Looking at ClassLoaderLogManager#addLogger(),
if a handler (requested by a ".handler" suffix property on a logger)
is not found, it is delegated to the parent configuration.

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Struggling to get trace/debug logging from Tomcat components

2025-03-14 Thread Christopher Schultz

Konstantin,

On 3/14/25 9:58 AM, Konstantin Kolinko wrote:

чт, 13 мар. 2025 г. в 20:37, Christopher Schultz :


Konstantin,

On 3/13/25 12:34 PM, Christopher Schultz wrote:

Konstantin,

On 3/13/25 10:55 AM, Konstantin Kolinko wrote:

чт, 13 мар. 2025 г. в 16:42, Christopher Schultz
:


All,

I really should be able to figure this out for myself but I'm frustrated
and might just need someone to show me that I'm spelling something
wrong.

I'm trying to get all logs from the CsrfPReventionFilter. I know it's
working because I get 403 responses when it's enabled and don't get them
when it's not. But it's 100% silent and I'm getting no logs.

I've added this to the bottom of the stock conf/logging.properties file:

org.apache.catalina.filters.CsrfPreventionFilter.level = ALL
org.apache.catalina.filters.CsrfPreventionFilter.handlers =
java.util.logging.ConsoleHandler

I shouldn't need the second line, since the default .handlers is
ConsoleHandler and the async handler for catalina.[date].

I'm not seeing anything more detailed than INFO in catalina.out or
catalina.[date]. But...

1catalina.org.apache.juli.AsyncFileHandler.level = ALL
...
java.util.logging.ConsoleHandler.level = ALL


??!

This is Tomcat 9.0.98 on Linux with a stock conf/logging.properties file
(plus my .level=ALL for this filter)

What am I missing?


1. It may be that your web application has its own logging.properties
file in classpath,
thus it is preferred over the default one.


There is a logging.properties in my application's webapps/WEB-INF/
classes/logging.properties file but I wouldn't expect that to interfere
with Tomcat's logging.


One option to prevent such behaviour is to reconfigure Tomcat to use the
java.util.logging.LogManager from JRE instead of its own class.


I will try that if I get desperate. :)


[...]

Switching to the JDK's LogManager worked.

.
Logging configuration comes from TCCL

> > CsrfPreventionFilter is a Filter. A Filter belongs to a web

application (unlike a Valve that may belong to a Host and in that case
will be shared). Thus logging for that filter may be configured
separately per web application. The "log" field in
CsrfPreventionFilter is intentionally an instance field, not a static
field.


Aha. I wasn't thinking about that at all. The Filter runs "inside" the 
application, so I need to use application-level configuration for 
logging. I'll try that, next.


-chris


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org