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