On 5/20/2013 2:45 PM, Nick Williams wrote:
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
Hopefully sometime this year (currently porting one of those types of
applications).
I do have a Maven artifact with some utility listeners that I make use
of (including a log4j listener). I just add the dependency, modify the
web.xml accordingly, and I'm good to go.
Yes, annotations would make things a little less cumbersome. However, I
still like seeing everything. Maybe once I get a bit more comfortable
with servlet spec 3.0, I'll rely on logEffectiveWebXml in Tomcat's
context.xml to troubleshoot rather than seeing the configuration explicitly.
I'm not sure how you would produce this in other servelt containers or
servers, though.
. . . just my two cents.
/mde/
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
