The default context selector is ClassLoaderContextSelector which creates a LoggerContext for each ClassLoader. This means that if you were to start and stop a bundle the Logging environment for that bundle should clean up. When you use the BasicContextSelector there is only a single LoggerContext for the whole application. As to which is correct for an OSGi environment I couldn’t say. If we need a context selector specifically for OSGi environments that can certainly be implemented, but we would have to know what the expected behavior is. Of course, you can always implement it and submit it as a patch to a Jira issue.
Ralph > On Jul 25, 2018, at 9:44 AM, Leon Finker <leon...@gmail.com> wrote: > > Hi, > > Use case: provide log4j2 logging in Felix OSGi application. Nothing OSGi > specific as far as logging concerned. Simply need to log all logging events > to configured log file for the application. Using async logging. > > If we run log4j2 (any current version) with default context selector, then we > noticed that each OSGi bundle creates a separate AsyncLoggerConfig* thread > with its own Disruptor, RingBuffer, etc. We have about 30+ bundles. Only by > setting Log4jContextSelector to > org.apache.logging.log4j.core.selector.BasicContextSelector, this is > prevented and one AsyncLoggerConfig/Disruptor/RingBuffer is created. > > Is this expected? > > --------------------------------------------------------------------- > 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
