On May 20, 2013, at 2:59 PM, Christopher Schultz wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Nick, > > On 5/20/13 12:48 PM, Nick Williams wrote: >> >> On May 20, 2013, at 10:56 AM, Christopher Schultz wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>> >>> Nick, >>> >>> On 5/19/13 11:25 AM, Nick Williams wrote: >>>> Unfortunately, requiring users to call System.gc() before >>>> shutdown for logging to work properly is no better than >>>> requiring users to register a listener in a web application for >>>> logging to work properly. Surely there's a better way... >>> >>> Do you initialize your logging system in a >>> ServletContextListener (or similar)? If so, then you should >>> destroy it at the same level. >>> >>> If you aren't initializing your logging system in a >>> ServletContextListener... then how are you initializing it? >>> >>> Long ago, I abandoned log4j's auto-initialization primarily >>> because it sometimes guesses wrong. >> >> First, remember that this is Log4j 2, so things are obviously >> different. > > It's different, but it's the same. > >> Log4j initializes with the first call to LogManager#getLogger(), >> whenever that occurs. In my case loggers are static, so it happens >> when the classes are initialized. In the specific case of the >> replication project attached to the issue, it happens on the first >> request to the only Servlet in the application. > > Right. What I'm saying is that you should take full control over the > initialization (and destruction) of the logging system. Your > ServletContextListeners should be invoked before your servlet classes > are loader.
And I'm saying you shouldn't /have/ to. It should "just work" without you having to do much thinking. See below. > >> Unfortunately, I've just about given up on it being possible to >> make logging work "right" without a ServletContextListener. Man oh >> man did I want to avoid that... > > You act like a ServletContextListener is some evil hack that should be > avoided at all costs. Instead, it's exactly the right mechanism to do > what you are trying to do: configure something at webapp launch and > de-configure it when the webapp is stopped. Not what I'm saying at all. I love listeners. They are extremely helpful, and I use them all the time. What I'm saying is that the concept of logging, philosophically, is supposed to be as unobtrusive as possible. Something you don't really have to think about how exactly it works; you just know to get a logger and put logging statements in your code and things "just work." The act of having to set up a listener to initialize and deinitialize logging, to me, seems like more than Log4j users should have to worry about. Perhaps just as importantly, Log4j 1 worked without a listener to initialize/deinitialize, so this is yet again one more thing users are going to have to do to switch from Log4j 1 to Log4j 2. Thankfully, we can use web-fragments in Servlet 3.0 and higher to configure the listener behind-the-scenes without the user even knowing. That's much more acceptable in my book. Users of Servlet 2.5 will still have to declare them manually, but I think they will probably be the minority users. So with a little more polishing of the Log4j 2 source code we can make this a little better. I just wish there was a solution that would work for both standalone applications /and/ web applications to initialize and deinitialize Log4j correctly without any users (including Servlet 2.5 users) having to think about it. Nick --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
