You still raise an interesting question about the LoggerContext thing.
I've never really understood the "current context" boolean argument
and whether or not that ever works properly. I think in theory, the
current context is supposed to cache whatever the last seen
LoggerContext in that thread is which wouldn't work properly in, say,
a shared thread pool with multiple LoggerContexts active.
On Thu, 14 Nov 2019 at 15:34, Zellyn Hunter <zel...@gmail.com> wrote:
>
> After more experimentation, it appears that whatever plumbing we have
> between maven/bazel/etc. was dropping "Multi-Release: true" from the
> MANIFEST.MF file.
>
> ¯\_(ツ)_/¯
>
> On Thu, Nov 14, 2019 at 4:02 PM Zellyn Hunter <zel...@gmail.com> wrote:
> >
> > Further investigation and simplification:
> >
> > I created a very simple test class:
> >
> > package com.squareup.log4jtest;
> > public class Log4jTest {
> > public static void main(String args[]) {
> > org.apache.logging.log4j.Logger logger1 =
> > org.apache.logging.log4j.LogManager.getLogger(Log4jTest.class);
> > org.apache.logging.log4j.Logger logger2 =
> > org.apache.logging.log4j.LogManager.getLogger(Log4jTest.class.getName());
> > System.out.println(logger1.toString());
> > System.out.println(logger2.toString());
> > }
> > }
> >
> > I get the weird behavior when running with the maven/bazel api jar:
> >
> > java -cp Log4jTest.jar:maven-log4j-api-2.12.1.jar:log4j-core-2.12.1.jar
> > com.squareup.log4jtest.Log4jTest
> > ERROR StatusLogger No Log4j 2 configuration file found. Using default
> > configuration (logging only errors to the console), or user
> > programmatically provided configurations. Set system property
> > 'log4j2.debug' to show Log4j 2 internal initialization logging. See
> > https://logging.apache.org/log4j/2.x/manual/configuration.html for
> > instructions on how to configure Log4j 2
> > WARNING: sun.reflect.Reflection.getCallerClass is not supported. This
> > will impact performance.
> > com.squareup.log4jtest.Log4jTest:ERROR in 799f7e29
> > com.squareup.log4jtest.Log4jTest:ERROR in Default
> >
> > But it's working fine when I use the log4j jar downloaded from the log4j
> > site:
> >
> > java -cp Log4jTest.jar:log4j-api-2.12.1.jar:log4j-core-2.12.1.jar
> > com.squareup.log4jtest.Log4jTest
> > ERROR StatusLogger No Log4j 2 configuration file found. Using default
> > configuration (logging only errors to the console), or user
> > programmatically provided configurations. Set system property
> > 'log4j2.debug' to show Log4j 2 internal initialization logging. See
> > https://logging.apache.org/log4j/2.x/manual/configuration.html for
> > instructions on how to configure Log4j 2
> > com.squareup.log4jtest.Log4jTest:ERROR in 799f7e29
> > com.squareup.log4jtest.Log4jTest:ERROR in 799f7e29
> >
> >
> > There's not much difference between the .jar file. Only the manifest,
> > and build-data.properties. Unzipping and diffing them, I get:
> >
> > ~/tmp diff -r apache/ maven/
> > diff -r apache/META-INF/MANIFEST.MF maven/META-INF/MANIFEST.MF
> > 2,48c2,3
> > < Bundle-License: https://www.apache.org/licenses/LICENSE-2.0.txt
> > < Bundle-SymbolicName: org.apache.logging.log4j.api
> > < Built-By: rgoers
> > < Bnd-LastModified: 1565148668668
> > < Implementation-Vendor-Id: org.apache.logging.log4j
> > < Specification-Title: Apache Log4j API
> > < Log4jReleaseManager: Ralph Goers
> > < Bundle-DocURL: https://www.apache.org/
> > < Import-Package: org.apache.logging.log4j,org.apache.logging.log4j.mess
> > < age,org.apache.logging.log4j.simple,org.apache.logging.log4j.spi,org.
> > < apache.logging.log4j.status,org.apache.logging.log4j.util,org.osgi.fr
> > < amework;version="[1.6,2)",org.osgi.framework.wiring;version="[1.0,2)"
> > < ,sun.reflect;resolution:=optional
> > < Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.7))"
> > < Export-Package: org.apache.logging.log4j;uses:="org.apache.logging.log
> > < 4j.message,org.apache.logging.log4j.spi,org.apache.logging.log4j.util
> > < ";version="2.12.1",org.apache.logging.log4j.message;uses:="org.apache
> > < .logging.log4j.util";version="2.12.1",org.apache.logging.log4j.simple
> > < ;uses:="org.apache.logging.log4j,org.apache.logging.log4j.message,org
> > < .apache.logging.log4j.spi,org.apache.logging.log4j.util";version="2.1
> > < 2.1",org.apache.logging.log4j.spi;uses:="org.apache.logging.log4j,org
> > < .apache.logging.log4j.message,org.apache.logging.log4j.util";version=
> > < "2.12.1",org.apache.logging.log4j.status;uses:="org.apache.logging.lo
> > < g4j,org.apache.logging.log4j.message,org.apache.logging.log4j.spi";ve
> > < rsion="2.12.1",org.apache.logging.log4j.util;uses:="org.apache.loggin
> > < g.log4j.message,org.apache.logging.log4j.spi,org.osgi.framework";vers
> > < ion="2.12.1"
> > < Bundle-Name: Apache Log4j API
> > < Multi-Release: true
> > < Bundle-Activator: org.apache.logging.log4j.util.Activator
> > < Log4jReleaseVersion: 2.12.1
> > < Implementation-Title: Apache Log4j API
> > < Bundle-Description: The Apache Log4j API
> > < Implementation-Version: 2.12.1
> > < Specification-Vendor: The Apache Software Foundation
> > < Bundle-ManifestVersion: 2
> > < Bundle-Vendor: The Apache Software Foundation
> > < Tool: Bnd-3.5.0.201709291849
> > < Implementation-Vendor: The Apache Software Foundation
> > < Bundle-Version: 2.12.1
> > < X-Compile-Target-JDK: 1.7
> > < X-Compile-Source-JDK: 1.7
> > < Created-By: Apache Maven Bundle Plugin
> > < Build-Jdk: 1.8.0_144
> > < Specification-Version: 2.12.1
> > < Implementation-URL: https://logging.apache.org/log4j/2.x/log4j-api/
> > < Log4jReleaseKey: B3D8E1BA
> > ---
> > > Created-By: singlejar
> > > Target-Label: @maven//:org_apache_logging_log4j_log4j_api
> > Only in maven/: build-data.properties
> > ~/tmp cat maven/build-data.properties
> > build.target=bazel-out/darwin-fastbuild/bin/external/maven/v1/https/maven.global.square/artifactory/square-public/org/apache/logging/log4j/log4j-api/2.12.1/stamped_log4j-api-2.12.1.jar
> >
> > On Thu, Nov 14, 2019 at 2:17 PM Zellyn Hunter <zel...@gmail.com> wrote:
> > >
> > > 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
>
--
Matt Sicker <boa...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
