The typical class loader selector or bundle one are made with the assumption that you're hosting multiple applications in a single JVM. The basic one works fine when you have a single application per JVM.
On Wed, 25 Jul 2018 at 12:23, Leon Finker <[email protected]> wrote: > For our use case BasicContextSelector works as expected. We really don't > need one async logger, disruptor, thread, etc per class loader. > > On Wed, Jul 25, 2018, 1:12 PM Ralph Goers <[email protected]> > wrote: > > > 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 <[email protected]> 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: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > -- Matt Sicker <[email protected]>
