That sounds expected but improper behavior. I had initially used this context selector in an application where each bundle was essentially a microservice (or the entry bundle into a set of them making up a logical service), but I’m not sure if that’s a common way to use OSGi anymore (especially now that Docker and Kubernetes are so popular).
On Wed, Jul 25, 2018 at 11:44, 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 > > -- Matt Sicker <boa...@gmail.com>
