Thanks So much for the clarification Piotr. Will look into the ContextSelector section.
Thanks and regards Arulkumar Ponnusamy On Thu, Mar 24, 2022 at 2:21 PM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > 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 >
