I think the LoggerContextRule can fail to apply the provided configuration if
another thread happens to access a logger (re-initializing the default config)
after the rule has stopped the old context, but before it has initialized the
new one. We may be able to update it with a loop so it tries harder, ideally
throwing an exception if it fails to set the expected context.
Is there any chance another test may be leaking threads beyond the scope of the
test?
-ck
On Wed, Sep 29, 2021, at 14:33, Gary Gregory wrote:
> Another reason to stick to Maven ;-)
>
> On Wed, Sep 29, 2021, 14:32 Travis Spencer <tra...@curity.io> wrote:
>
> > Thanks, Gary, for the reply. Unfortunately, a -D approach means a ton
> > of Gradle voodoo. I can ask one of the witchdocers to help with that,
> > but will try to copy the technique used AsyncLoggerConfigErrorOnFormat
> > first. Will report back on how it goes either way. Happy to receive
> > additional suggestions in the meantime.
> >
> >
> > On Wed, Sep 29, 2021 at 8:08 PM Gary Gregory <garydgreg...@gmail.com>
> > wrote:
> > >
> > > I would suggest finding some baseline that works by using -D on the
> > command
> > > line definition of your CI.
> > >
> > > Gary
> > >
> > > On Wed, Sep 29, 2021, 12:12 Travis Spencer <tra...@curity.io> wrote:
> > >
> > > > Greetings, Log4j list.
> > > >
> > > > I am testing some extensions that I have made to my usage of Log4j.
> > > > This usage involves a custom log event factory. I set this in my
> > > > actual program on startup using a system property. Now, to test this
> > > > in a unit test, I'm trying to set a system property in the same sort
> > > > of way. To that end, I have a static block in the test and a JUnit
> > > > ClassRule like this:
> > > >
> > > > static
> > > > {
> > > > System.setProperty("log4j2.logEventFactory",
> > > > MyGoodLogEventFactory.class.getName());
> > > > }
> > > >
> > > > @ClassRule
> > > > public static LoggerContextRule _context = new
> > > > LoggerContextRule("myGoodConfig.xml");
> > > >
> > > > This works perfectly on my local machine. In our CI system, however,
> > > > this fails sometimes. If I run only this one test in the CI system, it
> > > > passes every time. If I run all unit tests, however, it usually fails,
> > > > but does occasionally succeed. The hypothesis is that it depends on
> > > > which unit test is run first and whether or not the Log4j subsystem is
> > > > initialized yet. If it's not, the system property above is set and
> > > > everything works. If the Log4j subsystem is initialized, however, by
> > > > the time this test runs, then the system property (and thus the log
> > > > event factory) is not used.
> > > >
> > > > To test this hypothesis, I updated the test to do this instead:
> > > >
> > > > static
> > > > {
> > > > System.setProperty("log4j2.logEventFactory",
> > > > MaskedLogEventFactory.class.getName());
> > > > LoggerContextRule context = new
> > LoggerContextRule("myGoodConfig.xml");
> > > > if (context.getLoggerContext() != null) context.reconfigure();
> > > > _context = context;
> > > > }
> > > >
> > > > @ClassRule
> > > > public static LoggerContextRule _context;
> > > >
> > > > This had no effect though, and the test still passed locally, passed
> > > > remotely if it was the only test run, but failed intermittently if run
> > > > as a part of the entire suite.
> > > >
> > > > Looking through the Log4j source, I only found one test that was
> > > > setting a custom log event factory,
> > > >
> > > >
> > src/test/java/org/apache/logging/log4j/core/async/AsyncLoggerConfigErrorOnFormat.java.
> > > > This test, however, doesn't use the LoggerContextRule to configure the
> > > > system. I really like this API for the tests and would like to
> > > > continue to use it.
> > > >
> > > > Can anyone offer me help in:
> > > >
> > > > 1. Confirming that my hypothesis is correct that the tests likely fail
> > > > intermittently due to the initialization state of the Log4j subsystem
> > > > 2. Suggest a way to make the rest more resilient
> > > >
> > > > TIA!
> > > >
> > > > Travis Spencer
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> > > > For additional commands, e-mail: log4j-user-h...@logging.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> > For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >
> >
>
