[logback-user] Avoid pre-initialization upon the first LoggerFactory.getILoggerFactory();

Adam Gent adam.gent at snaphop.com
Mon Jun 13 13:39:48 UTC 2016

I will tell you how we deal with this but you will have to first
listen to my soap box rant :)

This is a common problem with almost all Java logging where you have a
chicken or the egg issue of logging or configuration (respectively).

Right now Logging almost always wins (ie loads before configuration)
and because it loads first it thus must have its own configuration
framework. This is extremely annoying if you want to use a distributed
configuration management system (e.g. Archaius, Etc.d, Consul, etc...)
as the clients to these systems will invariable load up logging and
thus you cannot configure your logging system with these systems.

I have known about this issue for quite some time and I have been
meaning to email Ceki about it and ask what his thoughts are.
This is in fact one of the reasons why I pushed to add the Service
Loader mechanism to control initialization (see
https://github.com/qos-ch/logback/pull/181) and is one way you could
solve this problem.

The other way as David alluded to is just to load your configuration
before any logging happens. The trick to do that in a servlet
container I have found is to use a ServletContextListener as the entry
point and to do your loading of your configuration there. Make sure to
register the listener before any other listeners (ie further up on the
web.xml). You would do this for both web apps. I do this for other
reasons besides logging for legacy libraries that use system
properties. Passing system properties on the command line is IMO a
security hazard so I load them up from an external properties file.

I have been meaning to opensource more of our companies internal
configuration library that does not use any logging and thus is safe
to preload before logging does. I had started it here but had not
finished it:


On Mon, Jun 13, 2016 at 5:24 AM, Brice Dutheil <brice.dutheil at gmail.com> wrote:
> Hi David,
> Thanks for the reply, but I’m speaking about 2 web-apps (i.e. 2 war files)
> that are deployed by a single tomcat instance. That means I don’t have
> access to the main and as it is a single JVM I cannot use the system
> property, because both web-apps will now have the same value for app.name.
> Cheers,
> — Brice
> On Fri, Jun 10, 2016 at 12:36 PM, David Roussel
> <nabble at diroussel.xsmail.com> wrote:
>> Hi,
>> There are two ways to deal with this.
>> 1) Put your log initialisation at the top of your main() method, so
>> nothing else can run first.
>> 2) Specify the app name as a system property on the command line:
>>   java -Dapp.name=MyApp -jar myappjar
>> Thanks
>> David
>> On 10 Jun 2016, at 10:20, Brice Dutheil <brice.dutheil at gmail.com> wrote:
>> Hi,
>> I would like share a single log configuration for two web-apps that run on
>> the same container. Yet I want each web-app to log in separate files.
>> I tried different approach the best one is actually very close to some
>> solution I later found on the FAQ :
>> http://logback.qos.ch/faq.html#sharedConfiguration
>> LoggerContext loggerContext = (LoggerContext)
>> LoggerFactory.getILoggerFactory();
>> JoranConfigurator jc = new JoranConfigurator();
>> jc.setContext(loggerContext);
>> loggerContext.reset();
>> loggerContext.setName(appName); // use ${CONTEXT_NAME} in logback.xml
>> jc.doConfigure(Objects.requireNonNull(source, "Logback configuration is
>> missing"));
>> However for operation reasons we pass the configuration via the system
>> property logback.configurationFile, so what happens is that the first call
>> to LoggerFactory.getILoggerFactory() initialise the LoggerContext and
>> creates files with non initialised variables.
>> As I’m using the context name, the file names have default in their name
>> (this is the default value of the context name), if using variable I get a
>> filename with my-var-name_IS_UNDEFINED.
>> The question is : Is there proper way anyway to avoid this
>> pre-initialisation to avoid creating this empty file ?
>> I didn’t found any way to hook in the org.slf4j.LoggerFactory or
>> org.slf4j.impl.StaticLoggerBinder (of logback-classic).
>> — Brice
>> _______________________________________________
>> logback-user mailing list
>> logback-user at qos.ch
>> http://mailman.qos.ch/mailman/listinfo/logback-user
>> _______________________________________________
>> logback-user mailing list
>> logback-user at qos.ch
>> http://mailman.qos.ch/mailman/listinfo/logback-user
> _______________________________________________
> logback-user mailing list
> logback-user at qos.ch
> http://mailman.qos.ch/mailman/listinfo/logback-user

SnapHop (snaphop.com)
(twitter) @agentgt (linkedin) http://www.linkedin.com/in/agentgt
(cell) 781-883-5182

More information about the logback-user mailing list