<div dir="ltr">100% Agreed.<div class="gmail_extra"><br clear="all"><div><div data-smartmail="gmail_signature"><div>-- Brice</div></div></div>
<br><div class="gmail_quote">On Wed, Jun 29, 2016 at 4:47 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">To your point though the real issue is initialization of slf4j.<br>
<br>
Unfortunately it is extremely static for performance reasons.<br>
I wanted to push to put some sort of initialization hook in slf4j<br>
similar to logbacks Service Loader but I thought it was out of scope.<br>
<br>
Of course one of the tricks is to write your own logging wrapper also<br>
known as a slf4j bridge on top of an existing logging framework.<br>
Except that framework **better not support slf4j natively** otherwise<br>
you will have to basically fork the entire logging framework.<br>
<br>
I do think SLF4J is somewhat inherently flawed because of this or at<br>
least libraries that do not separate the bridge portion (logback being<br>
one of them). I understand the extremely minor albeit I suppose<br>
performance issues with an additional method call as to why native is<br>
a good thing.<br>
<br>
Regardless I am of the strong opinion given the cloud world we live in<br>
that configuration should load first and not the logging framework.<br>
Frameworks that control boot up should allow a hook for initialization<br>
that either does no logging or uses its own internal logging framework<br>
(I'm looking at you Spring).<br>
<br>
It is a good thing to have to separate logging implementations for<br>
phases. One that is responsible for boot up of the config<br>
framework.... in the case of Tomcat JULI works nice. And then slf4j<br>
for post config boot up. The problem is every library is getting SL4J<br>
support foisted on them. If all libraries switch to SL4J it becomes<br>
harder to do a two stage approach.<br>
<span><font color="#888888"><br>
-Adam<br>
</font></span><div><div><br>
<br>
<br>
On Mon, Jun 27, 2016 at 12:47 PM, Brice Dutheil <<a href="mailto:brice.dutheil@gmail.com" target="_blank">brice.dutheil@gmail.com</a>> wrote:<br>
> Thanks Adam, interesting project. However in the end I abandoned this way of<br>
> initializing logs.<br>
><br>
> Too bad logback / slf4j does'nt allow a way to give a configuration supplier<br>
> or some configuration hook.<br>
><br>
> -- Brice<br>
><br>
> On Mon, Jun 13, 2016 at 3:39 PM, Adam Gent <<a href="mailto:adam.gent@snaphop.com" target="_blank">adam.gent@snaphop.com</a>> wrote:<br>
>><br>
>> 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>
>><br>
>><br>
>> On Mon, Jun 13, 2016 at 5:24 AM, Brice Dutheil <<a href="mailto:brice.dutheil@gmail.com" target="_blank">brice.dutheil@gmail.com</a>><br>
>> wrote:<br>
>> > Hi David,<br>
>> ><br>
>> > Thanks for the reply, but I’m speaking about 2 web-apps (i.e. 2 war<br>
>> > 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<br>
>> > <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" target="_blank">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" target="_blank">brice.dutheil@gmail.com</a>><br>
>> >> wrote:<br>
>> >><br>
>> >> Hi,<br>
>> >><br>
>> >> I would like share a single log configuration for two web-apps that run<br>
>> >> 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<br>
>> >> 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<br>
>> >> name<br>
>> >> (this is the default value of the context name), if using variable I<br>
>> >> 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" target="_blank">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" target="_blank">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" target="_blank">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>
>> 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" target="_blank">781-883-5182</a><br>
>> _______________________________________________<br>
>> logback-user mailing list<br>
>> <a href="mailto:logback-user@qos.ch" target="_blank">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" target="_blank">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>
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" target="_blank">781-883-5182</a><br>
_______________________________________________<br>
logback-user mailing list<br>
<a href="mailto:logback-user@qos.ch" target="_blank">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></div>