I'm trying to tweak some logback functionality (custom Appenders and the like). In order to test it I would like to configure Logback and call its logging methods directly without going through sl4j.
The reason for this weird requirement is to be able to test logback functionality in an environment where also other SLF4J bridges are available.
So I want to do the stuff described when invoking JoranConfigurator directly without a reference to SLF4J.
There is a way to find out.
Here's the example how you can configure LOGBack
// Here we create context LoggerContext loggerContext = new LoggerContext(); // Initializer is used to enrich context with details ContextInitializer contextInitializer = new ContextInitializer(loggerContext); try { // Get a configuration file from classpath URL configurationUrl = Thread.currentThread().getContextClassLoader().getResource("custom-logback-configuration.xml"); if (configurationUrl == null) { throw new IllegalStateException("Unable to find custom logback configuration file"); } // Ask context initializer to load configuration into context contextInitializer.configureByResource(configurationUrl); // Here we get logger from context logger = loggerContext.getLogger(LogReporter.class); } catch (JoranException e) { throw new RuntimeException("Unable to configure logger", e); } In general if you want to know how any SLF4J backend works, you may just to look at org.slf4j.impl.StaticLoggerBinder class source from that backend.
Haven't tried it, but looks correct, maybe it will help:
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); ch.qos.logback.classic.Logger log = lc.getLogger(foo.Bar.class); The ch.qos.logback.classic.Logger implements org.slf4j.Logger but you can use it directly. You might need to obtain LoggerContext differently.
new LoggerContext() and avoiding SLF4J API completely?
LoggerContext logCtx = new LoggerContext(); worked for me. Why does java have to make logging a living hell?!Unfortunately, I don't think its possible. If you take a look at the Logback Logger source (or other classes) you will see it depends on slf4j.
This is not nice, imho, as logback should be unaware of slf4j.
NATIVE IMPLEMENTATION There are also SLF4J bindings external to the SLF4J project, e.g. logback which implements SLF4J natively. Logback's ch.qos.logback.classic.Logger class is a direct implementation of SLF4J's org.slf4j.Logger interface. Thus, using SLF4J in conjunction with logback involves strictly zero memory and computational overhead. slf4j.org/manual.html