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

Reply via email to