-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Nick,
On 5/20/13 4:10 PM, Nick Williams wrote: > > 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. That's like saying that aspect-oriented programming should "just work" without having to run the AOP compiler against the code, first. This at least used to be a problem in log4j 1 as well: you had to call LogManager.shutdown in order to free all the resources, flush all the buffers, etc. when your webapp unloaded, otherwise you ran the risk of pinning the old webapp's ClassLoader, etc. in memory. The only way to run LogManager.shutdown() on webapp unload is to configure a ServletContextListener. > 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. While I agree, it increases the amount of "magic" that I generally prefer to keep to a minimum. I know I'm apparently an old guy who just doesn't get it, but I honestly prefer explicit configuration to auto-configuration. You can diagnose problems much more easily with explicit configuration than by attaching a debugger and stepping-through the entire bootstrap process to figure out wtf is going on. > Users of Servlet 2.5 will still have to declare them manually, but > I think they will probably be the minority users. Ha ha ha. Don't you see the posts from people trying to figure out how to move their Tomcat 3.x installations to a new Windows 2000 server? Again, I'm a apparently a dinosaur, but I don't have a single servlet-3.0 webapp deployed in production anywhere. Not even in testing. > 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. The solution is to have a magic annotation-processor running all the time in the JVM, right? Isn't that what OSGi is for? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJRmpggAAoJEBzwKT+lPKRYQ24P/iPvZkN/WQIgYWCOHKFyLvFx Kjs6CfgW04AV/I4xHG/BvN8v/tAI03bAj8d1jaHNr8hkkhc9lWrp/pMG9Vx5jBLn wMm8a17QYbotyUZnd1XmYVGDyGSrsh/XTL1DmFZv+lih9HMMVqxCjklvLtvpdoXR NuCJlO0dyHdQa/tLw7QGe71JAWzNvmcWWe0n3znNk0RKFe3r94IohxVg/IqTA3dB Zd55qTovpkDWD8FWOGuCvY7v/bkqRmz/xp12KQ+AWrX6GBUiaMLmkAAYrcmeXD1e C+PFx1+VOCDu6a6tPkBI1gVa85cfhTqcZCtCm5i/3s95z3F5twUb31UdfkQIJh7K 2HhofaYT6EcCYmAaEREYWTogdRNNe/9YYaSzOIgBI9SzUP3uMFzcQ9gOu9doIQkg HETOyFJsJ2rpM6P52XLvNwRmuHeoXcFznL/VhIwwfGjhjAl1uGdwVbSYsCRHFP7c nuH+4FtC2PE1oQRm4nuu3E1wC6RWCxTZvlijcuve1qsh2csh4JgkKShiml8YqjNI mljpqBjIvAON7fDssEDjuFsdN5/TxvvY7R94Ezw+c/UaoXi2SAd0x7eJA2GIziPg pbIoAHN+Ux4xfAoU0vmBbV0bljhZNqEZTKrRK4y8o9NL2z3uGMT+/fNWpJweegB8 3GgxKah7JttN7hpjItm9 =zpE/ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
