<div dir="ltr">Thanks Adam, interesting project. However in the end I abandoned this way of initializing logs.<div><br></div><div>Too bad logback / slf4j does'nt allow a way to give a configuration supplier or some configuration hook.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div>-- Brice</div></div></div>
<br><div class="gmail_quote">On Mon, Jun 13, 2016 at 3:39 PM, Adam Gent <span dir="ltr"><<a href="mailto:adam.gent@snaphop.com" target="_blank">adam.gent@snaphop.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I will tell you how we deal with this but you will have to first<br>
listen to my soap box rant :)<br>
<br>
This is a common problem with almost all Java logging where you have a<br>
chicken or the egg issue of logging or configuration (respectively).<br>
<br>
Right now Logging almost always wins (ie loads before configuration)<br>
and because it loads first it thus must have its own configuration<br>
framework. This is extremely annoying if you want to use a distributed<br>
configuration management system (e.g. Archaius, Etc.d, Consul, etc...)<br>
as the clients to these systems will invariable load up logging and<br>
thus you cannot configure your logging system with these systems.<br>
<br>
I have known about this issue for quite some time and I have been<br>
meaning to email Ceki about it and ask what his thoughts are.<br>
This is in fact one of the reasons why I pushed to add the Service<br>
Loader mechanism to control initialization (see<br>
<a href="https://github.com/qos-ch/logback/pull/181" rel="noreferrer" target="_blank">https://github.com/qos-ch/logback/pull/181</a>) and is one way you could<br>
solve this problem.<br>
<br>
<br>
The other way as David alluded to is just to load your configuration<br>
before any logging happens. The trick to do that in a servlet<br>
container I have found is to use a ServletContextListener as the entry<br>
point and to do your loading of your configuration there. Make sure to<br>
register the listener before any other listeners (ie further up on the<br>
web.xml). You would do this for both web apps. I do this for other<br>
reasons besides logging for legacy libraries that use system<br>
properties. Passing system properties on the command line is IMO a<br>
security hazard so I load them up from an external properties file.<br>
<br>
I have been meaning to opensource more of our companies internal<br>
configuration library that does not use any logging and thus is safe<br>
to preload before logging does. I had started it here but had not<br>
finished it:<br>
<a href="https://github.com/agentgt/configfacade" rel="noreferrer" target="_blank">https://github.com/agentgt/configfacade</a><br>
<br>
-Adam<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Mon, Jun 13, 2016 at 5:24 AM, Brice Dutheil <<a href="mailto:brice.dutheil@gmail.com">brice.dutheil@gmail.com</a>> wrote:<br>
> Hi David,<br>
><br>
> Thanks for the reply, but I’m speaking about 2 web-apps (i.e. 2 war files)<br>
> that are deployed by a single tomcat instance. That means I don’t have<br>
> access to the main and as it is a single JVM I cannot use the system<br>
> property, because both web-apps will now have the same value for <a href="http://app.name" rel="noreferrer" target="_blank">app.name</a>.<br>
><br>
> Cheers,<br>
> — Brice<br>
><br>
> On Fri, Jun 10, 2016 at 12:36 PM, David Roussel<br>
> <<a href="mailto:nabble@diroussel.xsmail.com">nabble@diroussel.xsmail.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> There are two ways to deal with this.<br>
>><br>
>> 1) Put your log initialisation at the top of your main() method, so<br>
>> nothing else can run first.<br>
>><br>
>> 2) Specify the app name as a system property on the command line:<br>
>><br>
>>   java -Dapp.name=MyApp -jar myappjar<br>
>><br>
>> Thanks<br>
>><br>
>> David<br>
>><br>
>> On 10 Jun 2016, at 10:20, Brice Dutheil <<a href="mailto:brice.dutheil@gmail.com">brice.dutheil@gmail.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> I would like share a single log configuration for two web-apps that run on<br>
>> the same container. Yet I want each web-app to log in separate files.<br>
>><br>
>> I tried different approach the best one is actually very close to some<br>
>> solution I later found on the FAQ :<br>
>> <a href="http://logback.qos.ch/faq.html#sharedConfiguration" rel="noreferrer" target="_blank">http://logback.qos.ch/faq.html#sharedConfiguration</a><br>
>><br>
>> LoggerContext loggerContext = (LoggerContext)<br>
>> LoggerFactory.getILoggerFactory();<br>
>> JoranConfigurator jc = new JoranConfigurator();<br>
>> jc.setContext(loggerContext);<br>
>> loggerContext.reset();<br>
>> loggerContext.setName(appName); // use ${CONTEXT_NAME} in logback.xml<br>
>> jc.doConfigure(Objects.requireNonNull(source, "Logback configuration is<br>
>> missing"));<br>
>><br>
>> However for operation reasons we pass the configuration via the system<br>
>> property logback.configurationFile, so what happens is that the first call<br>
>> to LoggerFactory.getILoggerFactory() initialise the LoggerContext and<br>
>> creates files with non initialised variables.<br>
>><br>
>> As I’m using the context name, the file names have default in their name<br>
>> (this is the default value of the context name), if using variable I get a<br>
>> filename with my-var-name_IS_UNDEFINED.<br>
>><br>
>> The question is : Is there proper way anyway to avoid this<br>
>> pre-initialisation to avoid creating this empty file ?<br>
>><br>
>> I didn’t found any way to hook in the org.slf4j.LoggerFactory or<br>
>> org.slf4j.impl.StaticLoggerBinder (of logback-classic).<br>
>><br>
>> — Brice<br>
>><br>
>> _______________________________________________<br>
>> logback-user mailing list<br>
>> <a href="mailto:logback-user@qos.ch">logback-user@qos.ch</a><br>
>> <a href="http://mailman.qos.ch/mailman/listinfo/logback-user" rel="noreferrer" target="_blank">http://mailman.qos.ch/mailman/listinfo/logback-user</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> logback-user mailing list<br>
>> <a href="mailto:logback-user@qos.ch">logback-user@qos.ch</a><br>
>> <a href="http://mailman.qos.ch/mailman/listinfo/logback-user" rel="noreferrer" target="_blank">http://mailman.qos.ch/mailman/listinfo/logback-user</a><br>
><br>
><br>
> _______________________________________________<br>
> logback-user mailing list<br>
> <a href="mailto:logback-user@qos.ch">logback-user@qos.ch</a><br>
> <a href="http://mailman.qos.ch/mailman/listinfo/logback-user" rel="noreferrer" target="_blank">http://mailman.qos.ch/mailman/listinfo/logback-user</a><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
CTO<br>
SnapHop (<a href="http://snaphop.com" rel="noreferrer" target="_blank">snaphop.com</a>)<br>
(twitter) @agentgt (linkedin) <a href="http://www.linkedin.com/in/agentgt" rel="noreferrer" target="_blank">http://www.linkedin.com/in/agentgt</a><br>
(cell) <a href="tel:781-883-5182" value="+17818835182">781-883-5182</a><br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
logback-user mailing list<br>
<a href="mailto:logback-user@qos.ch">logback-user@qos.ch</a><br>
<a href="http://mailman.qos.ch/mailman/listinfo/logback-user" rel="noreferrer" target="_blank">http://mailman.qos.ch/mailman/listinfo/logback-user</a></div></div></blockquote></div><br></div>