Hi John, You're right, but note that this affects the level the broker/connect worker was _reporting_ for that logger, not the level at which the logger was actually logging, which would be TRACE both before and after upgrading.
I've added more of an explanation to the KIP, since it wasn't very clear. Thanks for taking a look. Tom On Wed, Oct 7, 2020 at 4:29 PM John Roesler <vvcep...@apache.org> wrote: > Thanks for this KIP Tom, > > Just to clarify the impact: In your KIP you described a > situation in which the root logger is configured at INFO, an > "kafka.foo" is configured at TRACE, and then "kafka.foo.bar" > is resolved to INFO. > > Assuming this goes into 3.0, would it be the case that if I > had the above configuration, after upgrade, "kafka.foo.bar" > would just switch from INFO to TRACE on its own? > > It seems like it must, since it's not configured explicitly, > and we are changing the inheritance rule from "inherit > directly from root" to "inherit from the closest configured > ancestor in the hierarchy". > > Am I thinking about this right? > > Thanks, > -John > > On Wed, 2020-10-07 at 15:42 +0100, Tom Bentley wrote: > > Hi all, > > > > I would like to start discussion on a small KIP which seeks to rectify an > > inconsistency between how Kafka reports logger levels and how logger > > configuration is inherited hierarchically in log4j. > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-676%3A+Respect+logging+hierarchy > > < > https://cwiki.apache.org/confluence/display/KAFKA/KIP-676%3A+Respect+logging+hierarchy?moved=true > > > > > > If you have a few minutes to have a look I'd be grateful for any > feedback. > > > > Many thanks, > > > > Tom > >
