Perhaps to put it more succinctly, why are these loggers different?
org.apache.logging.log4j.Logger logger1 =
org.apache.logging.log4j.LogManager.getLogger(LogGrabberTest.class);
org.apache.logging.log4j.Logger logger2 =
org.apache.logging.log4j.LogManager.getLogger(LogGrabberTest.class.getName());
Here's what IntelliJ's debug pane says after these lines execute:
logger1 = {Logger@2317}
"com.squareup.logging.utils.LogGrabberTest:ERROR in 579bb367"
logger2 = {Logger@2318}
"com.squareup.logging.utils.LogGrabberTest:ERROR in Default"
I would like to stop this from happening, but more importantly
understand (a) what is going on, and (b) why the FAQ answer for
setting a log level programmatically gives me a solution that doesn't
work, because it's dealing with different LoggerContexts.
Thanks,
Zellyn
On Thu, Nov 14, 2019 at 12:45 PM Zellyn Hunter <zel...@gmail.com> wrote:
>
> Hi folks,
>
> Please help me develop a mental model of what's going on with
> LoggerContexts here.
>
> I'm trying to get the following to work (log4j 2.12.1):
>
> org.apache.logging.log4j.Logger logz =
> org.apache.logging.log4j.LogManager.getLogger(LogGrabberTest.class);
> org.apache.logging.log4j.LogManager.getContext(false); // just for
> testing
>
> org.apache.logging.log4j.core.config.Configurator.setLevel(LogGrabberTest.class.getName(),
> Level.DEBUG);
>
> However, the level is never getting set. If I watch instances of
> LoggerContext in IntelliJ's debug, I can see that after the first
> line, one named "579bb367" is created, but the second (and/or third)
> line causes one to be created named "Default". Then, the logger logz
> is never updated.
>
> If I add a config file to my classpath named
> log4j2.component.properties, with the value
> Log4jContextSelector=org.apache.logging.log4j.core.selector.BasicContextSelector,
> I can get it to work.
>
> However, I would like to not have to do that everywhere, and would
> very much like to understand why the ClassLoaderContextSelector is
> failing. This code all lives inside LogGrabberTest, so I'm not
> reaching across JAR/WAR/etc. boundaries or anything.
>
> This code all worked in Pants, I think because it just smooshes all
> the classes together into one Jar.
>
> Thanks,
>
> Zellyn
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
