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

Fri Jul 8 16:12:04 UTC 2016

100% Agreed.

-- Brice

On Wed, Jun 29, 2016 at 4:47 PM, Adam Gent <adam.gent at snaphop.com> wrote:

> To your point though the real issue is initialization of slf4j.
>
> Unfortunately it is extremely static for performance reasons.
> I wanted to push to put some sort of initialization hook in slf4j
> similar to logbacks Service Loader but I thought it was out of scope.
>
> Of course one of the tricks is to write your own logging wrapper also
> known as a slf4j bridge on top of an existing logging framework.
> Except that framework **better not support slf4j natively** otherwise
> you will have to basically fork the entire logging framework.
>
> I do think SLF4J is somewhat inherently flawed because of this or at
> least libraries that do not separate the bridge portion (logback being
> one of them). I understand the extremely minor albeit I suppose
> performance issues with an additional method call as to why native is
> a good thing.
>
> Regardless I am of the strong opinion given the cloud world we live in
> that configuration should load first and not the logging framework.
> Frameworks that control boot up should allow a hook for initialization
> that either does no logging or uses its own internal logging framework
> (I'm looking at you Spring).
>
> It is a good thing to have to separate logging implementations for
> phases. One that is responsible for boot up of the config
> framework.... in the case of Tomcat JULI works nice. And then slf4j
> for post config boot up. The problem is every library is getting SL4J
> support foisted on them. If all libraries switch to SL4J it becomes
> harder to do a two stage approach.
>
> -Adam
>
>
>
> On Mon, Jun 27, 2016 at 12:47 PM, Brice Dutheil <brice.dutheil at gmail.com>
> wrote:
> > 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
> >
> >
> >
> > _______________________________________________
> > 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/20160708/e36f63a0/attachment.html>