On May 20, 2013, at 4:39 PM, Christopher Schultz wrote: > -----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.
Oh, I see the posts. I just figure if they're that far behind they won't be using Log4j 2 for at least another 10 years. Nick > >> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
