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 <[email protected]> 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 <[email protected]> > 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 > > <[email protected]> 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 <[email protected]> > 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 > >> [email protected] > >> http://mailman.qos.ch/mailman/listinfo/logback-user > >> > >> > >> > >> _______________________________________________ > >> logback-user mailing list > >> [email protected] > >> http://mailman.qos.ch/mailman/listinfo/logback-user > > > > > > _______________________________________________ > > logback-user mailing list > > [email protected] > > 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 > [email protected] > http://mailman.qos.ch/mailman/listinfo/logback-user >
_______________________________________________ logback-user mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/logback-user
