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

[Brice Dutheil]

Thanks Adam, interesting project. However in the end I abandoned this way
of initializing logs.

Too bad logback / slf4j does'nt allow a way to give a configuration
supplier or some configuration hook.

-- Brice

On Mon, Jun 13, 2016 at 3:39 PM, Adam Gent <adam.gent at snaphop.com> wrote:

> 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:
> https://github.com/agentgt/configfacade
>
> -Adam
>
>
> 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
>
>
>
> --
> CTO
> SnapHop (snaphop.com)
> (twitter) @agentgt (linkedin) http://www.linkedin.com/in/agentgt
> (cell) 781-883-5182
> _______________________________________________
> logback-user mailing list
> logback-user at qos.ch
> http://mailman.qos.ch/mailman/listinfo/logback-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/logback-user/attachments/20160627/f5e08492/attachment.html>