At 17:45 21.04.2001 -0700, you wrote:
>My two cents as a Log4J User.
>
>I use Log4J in my servlets and I think it great. Logging has never been so easy.
>One issue though, the Configurator class holds it data in a Static variable so
>two servlets inside the same JVM will each over write the others config. Even
>since I implemented Log4J I was worried that my servlets may not play well
>with others when trying to deploy at an ISP.
John,
As far as I know, the PropertyConfigurator and the DOMConfigurator do not hold any
static info. You are free to use them as many times as you want. By default, the log4j
configurators act on the default hierarchy although it is possible to specify a custom
hierarchy. Having said that, if you configure the same hierarchy multiple times, then
each reconfiguration will be merged with the existing configuration. This is known to
confuse people but it offers real advantages.
If that is not the behavior that you desire, then you can call h.resetConfiguration(),
for some hierarchy object h, before reconfiguring. Similarly, use
Category.getDefaultHierarchy().resetConfiguration() for resetting the default
hierarchy before reconfiguring.
>Also will you be able to support
>one Servlet using a PropertyConfigurastion as opposed to a XMLConfigurator.
Mixing configurators is not a problem.
>A word to the wise, one of our biggest hurdles was where or when to use each
>level. i.e. Debug,Info,warn.. It is easy to always use Info or Debug which defeats
>the purpose of separate levels. We had to create a standards document that defined
>where to implement each. It was surprising how often I need to look at the document
>to make the right choice.
Log4j has a rather limited set of priorities specifically to avoid the sort confusion
you describe. One of the most important lessons I learned during my formal engineering
education was to avoid functionality that could not be clearly understood by a
competent audience. My hereto assumption was that DEBUG, INFO, WARN, ERROR and FATAL
was the largest set of priorities with no possible confusion. You seem to think
otherwise. I would be very interested in peeking at your standards document and
perhaps include it in the log4j distribution with your permission of course.
TIA, Ceki
