Hi Arulkumar, On Thu, 24 Mar 2022 at 07:30, Arulkumar Ponnusamy <parul....@gmail.com> wrote:
> 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 text. 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 https://logging.apache.org/log4j/2.x/manual/extending.html#ContextSelector) with something better suited for full Java EE application servers. I believe the `JndiContextSelector` might be the right choice. Piotr [1] https://issues.apache.org/jira/browse/LOG4J2-3330
