Oh, I see what you’re saying. That’s definitely a bug. Please file a ticket in JIRA about it. Pull requests are welcome!
On Thu, Jul 26, 2018 at 09:44, Leon Finker <leon...@gmail.com> wrote: > Right. We have few cases of using OSGi in plug-in jars like use cases. In > that case, when using > > -DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector > new AsyncLogger thread, Disruptor, etc is started per class loader where > logging was used. > > In one application we specify > -DLog4jContextSelector=org.apache.logging.log4j.core.selector.BasicContextSelector > and use AsyncRoot and AsyncLogger in log4j2 configuration. In that case > only one AsyncLogger is created. > > I guess there is no way to have one AsyncLogger for the application when > using pure async logging mode under OSGi like/different classloader setup. > > On 2018/07/25 19:02:53, Matt Sicker <boa...@gmail.com> wrote: > > 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 <leon...@gmail.com> 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 <ralph.go...@dslextreme.com> > > > 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 <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 > > > > > > > > > > > > > > > > > -- > > Matt Sicker <boa...@gmail.com> > > > > --------------------------------------------------------------------- > 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>
