Logger.setLevel() not supported in 2.0?

[Merten Schumann]

Hello,

from "Converting to the Log4j 2 API":
Calls to org.apache.log4j.Logger.setLevel() or similar methods are not supported in the API.
Applications should remove these.

Could imagine the reason, checking getLevel() is final, so it's quick.
But, when you have in your program your good old fixed static Logger log, it's often helpful to toggle its logger level at runtime, when the method that should be investigated is reached in the code or in the debugger ... enable DEBUG output and disable it again ...

Am I missing something? Nobody else missing this feature? :-)

Thanx
Merten

[Ralph Goers]

In Log4j 2 Logger.setLevel() might now work the way you would expect. It would change the level of the specific logger, but it would not affect child loggers. So if you had a Logger(com.foo) and Logger(com.foo.bar), which both had effective levels of “error” and then you called setLevel on Logger(com.foo) with “debug”, events logged to Logger(com.foo.bar) would still be at “error”. To change the level in a manner similar to Log4j 1 you would want to obtain the appropriate LoggerConfig, change its Level and then call the LoggerContext’s updateLoggers() method. Needless to say, this is not something that is exposed at the API layer and ties you to the specifics of how Log4j 2 is implemented.

FWIW, changing the Level of the LoggerConfig is supported via JMX, so you can create tooling that interacts with that.

Ralph

Post by Merten Schumann
Hello,
Calls to org.apache.log4j.Logger.setLevel() or similar methods are not supported in the API.
Applications should remove these.
Could imagine the reason, checking getLevel() is final, so it's quick.
But, when you have in your program your good old fixed static Logger log, it's often helpful to toggle its logger level at runtime, when the method that should be investigated is reached in the code or in the debugger ... enable DEBUG output and disable it again ...
Am I missing something? Nobody else missing this feature? :-)
Thanx
Merten

[Merten Schumann]

Well, the behavior of setLevel() in Log4j 1 in conjunction with logger hierarchies ... is unexpected, yes. ;-)

So there is no public(ly supported) way to change a Logger's level in Log4j 2 - okay, I'll just miss it.

We've got an API here offering some public documented our.own.Logger instances - including a setLevel() method at the public interface, Log4j 1 is one of the logging implementations supported.
I think we could implement a work around for our setLevel() method, when we want or have to support Log4j 2 - behind the scenes we could create multiple Logger instances for the same logical name but the appropriate Logger level and redirect to the correct one then. Not perfect but could work.

Just found, the creation of Logger instances seems not to support specifying the level directly/programmatically ... aha, there seems to be a way via an own LoggerConfig implementation. :-)

Thank you, Ralph!
Merten

-----Original Message-----
From: Ralph Goers [mailto:***@dslextreme.com]
Sent: Wednesday, July 23, 2014 5:26 PM
To: Log4J Users List
Subject: Re: Logger.setLevel() not supported in 2.0?

In Log4j 2 Logger.setLevel() might now work the way you would expect. It would change the level of the specific logger, but it would not affect child loggers. So if you had a Logger(com.foo) and Logger(com.foo.bar), which both had effective levels of "error" and then you called setLevel on Logger(com.foo) with "debug", events logged to Logger(com.foo.bar) would still be at "error". To change the level in a manner similar to Log4j 1 you would want to obtain the appropriate LoggerConfig, change its Level and then call the LoggerContext's updateLoggers() method. Needless to say, this is not something that is exposed at the API layer and ties you to the specifics of how Log4j 2 is implemented.

FWIW, changing the Level of the LoggerConfig is supported via JMX, so you can create tooling that interacts with that.

Ralph

Post by Merten Schumann
Hello,
Calls to org.apache.log4j.Logger.setLevel() or similar methods are not supported in the API.
Applications should remove these.
Could imagine the reason, checking getLevel() is final, so it's quick.
But, when you have in your program your good old fixed static Logger log, it's often helpful to toggle its logger level at runtime, when the method that should be investigated is reached in the code or in the debugger ... enable DEBUG output and disable it again ...
Am I missing something? Nobody else missing this feature? :-)
Thanx
Merten

[Matt Sicker]

You can always reconfigure your loggers at runtime by modifying the config
file. Another way would be to force a reconfigure() with a custom
ConfigurationFactory or similar.

Post by Merten Schumann
Well, the behavior of setLevel() in Log4j 1 in conjunction with logger
hierarchies ... is unexpected, yes. ;-)
So there is no public(ly supported) way to change a Logger's level in
Log4j 2 - okay, I'll just miss it.
We've got an API here offering some public documented our.own.Logger
instances - including a setLevel() method at the public interface, Log4j 1
is one of the logging implementations supported.
I think we could implement a work around for our setLevel() method, when
we want or have to support Log4j 2 - behind the scenes we could create
multiple Logger instances for the same logical name but the appropriate
Logger level and redirect to the correct one then. Not perfect but could
work.
Just found, the creation of Logger instances seems not to support
specifying the level directly/programmatically ... aha, there seems to be a
way via an own LoggerConfig implementation. :-)
Thank you, Ralph!
Merten
-----Original Message-----
Sent: Wednesday, July 23, 2014 5:26 PM
To: Log4J Users List
Subject: Re: Logger.setLevel() not supported in 2.0?
In Log4j 2 Logger.setLevel() might now work the way you would expect. It
would change the level of the specific logger, but it would not affect
child loggers. So if you had a Logger(com.foo) and Logger(com.foo.bar),
which both had effective levels of "error" and then you called setLevel on
Logger(com.foo) with "debug", events logged to Logger(com.foo.bar) would
still be at "error". To change the level in a manner similar to Log4j 1
you would want to obtain the appropriate LoggerConfig, change its Level and
then call the LoggerContext's updateLoggers() method. Needless to say,
this is not something that is exposed at the API layer and ties you to the
specifics of how Log4j 2 is implemented.
FWIW, changing the Level of the LoggerConfig is supported via JMX, so you
can create tooling that interacts with that.
Ralph

Post by Merten Schumann
Hello,
Calls to org.apache.log4j.Logger.setLevel() or similar methods are not

supported in the API.

Post by Merten Schumann
Applications should remove these.
Could imagine the reason, checking getLevel() is final, so it's quick.
But, when you have in your program your good old fixed static Logger

log, it's often helpful to toggle its logger level at runtime, when the
method that should be investigated is reached in the code or in the
debugger ... enable DEBUG output and disable it again ...

Post by Merten Schumann
Am I missing something? Nobody else missing this feature? :-)
Thanx
Merten

---------------------------------------------------------------------

[Chris Graham]

I certainly would!

I often leave a logger (yes, a static one) in info model and change levels depending on what is going in. Ie, kick it into debug mode as needed. Saves from a lot of scroll blindness.

-Chris

Sent from my iPhone

Post by Merten Schumann
Hello,
Calls to org.apache.log4j.Logger.setLevel() or similar methods are not supported in the API.
Applications should remove these.
Could imagine the reason, checking getLevel() is final, so it's quick.
But, when you have in your program your good old fixed static Logger log, it's often helpful to toggle its logger level at runtime, when the method that should be investigated is reached in the code or in the debugger ... enable DEBUG output and disable it again ...
Am I missing something? Nobody else missing this feature? :-)
Thanx
Merten