Hi Arulkumar,

On Thu, 24 Mar 2022 at 07:30, Arulkumar Ponnusamy <parul....@gmail.com>

> However, What i noticed is, the Configurator.setLevel() method's
> Logger.getContext has a different reference id whereas the actual class's
> LoggerFactory.getLogger(class) has a different context id. I guess, because
> of this, the update does not send the notification properly so that the
> actual change is not reflected. Attached the snapshot, the first image is
> for the level setting using *Configurator.setlevel(*) and the second
> image is the actual class where actual logs are printed.
> what i noticed is, when the

Images are not accepted in the mailing list, please provide any code as

The problem you are observing is due to the caller sensitivity of various
Log4j2 functions, which have an implicit `LoggerContext` parameter. The
change in behavior you observe is due to the fix of LOG4J-3330[1]. The fix
itself is correct, as far as I can tell, but it modifies your program's
behavior: `Configurator#setLevel` updates the `LoggerContext` associated
with the classloader of the caller.

I don't know the specifics of how WildFly manages classloaders, but IIRC
there can be multiple classloaders per application. You should consider
swapping the default `ClassLoaderContextSelector` (see
with something better suited for full Java EE application servers. I
believe the `JndiContextSelector` might be the right choice.


[1] https://issues.apache.org/jira/browse/LOG4J2-3330

Reply via email to