Howdy,
If we think it is a good, useful example of a repository selector, and
to
be useful it needs to live at the same location as the log4j jar, why
should we not include it in the official distribution? When does it
become core, in
your opinion? In my mind, it may be possible that the log4j
Yep,
There is no harm in using Log4j within WEB-INF/lib even if Log4j exists in
a parent classloader. It doesn't affect any other apps the the current app
is free to use whatever version of the jars they want. In the context of
using a repository selector, putting log4j.jar in the
Howdy Jacob,
Actually, If you look in my post, I mention more than just the
Log4jInit servlet. I also mention a servlet context listener
(SCL) called
Log4jApplicationWatch. I actually use that currently to do cleanup
such as shutting down loggers and appenders of the currently used
Actually, the main thing I'd propose is having Log4jCRS (Log4j
Contextual Repository Selector) be included with the Log4j
distribution. The reasons for this are described in my post
that Mark
linked to above.
I know this is not a vote, but +1 on that. As part of the
contrib tree,
not
One possible one-shot-kill-all-birds solution is to use the JNDI
space. See the updated version of http://www.qos.ch/logging/sc.html
(in particular JNDIRS). What do you think?
I also suggested the JNDI solution in commons-dev in a somewhat
different context. It seemed to be well received.
At 15:54 12.12.2002 -0800, Mark Womack wrote:
One possible one-shot-kill-all-birds solution is to use the JNDI
space. See the updated version of http://www.qos.ch/logging/sc.html
(in particular JNDIRS). What do you think?
I also suggested the JNDI solution in commons-dev in a somewhat
Yes, we can reasonably do that. However, I am unsure about the
maturity of any of these approaches without proper
testing/analysis. Consequently, we should include these selectors
assuming that they are visibly marked as experimental. Their inclusion
might spur Container developers to refine
