> From: Wolfram Rittmeyer [mailto:[EMAIL PROTECTED]]
>
> log4j is already in the lib-path (though not the actual one -
> you still have to use Category instead of Logger for
> instance). It works perfectly well in conjunction with
> JMeter. And log4j is already in use - though not in general.
> If you swith to DEFAULT (in bin/log4j.conf) you already get a
> whole lot of logging.
>
> Anyway: I agree with you that this should be the normal way
> of dealing with any output that has to be generated (e.g.
> TableVisualizer/TableDataModel produces a lot of
> System.out-messages). Maybe we could even migrate to the
> commons-logging-library since this would allow JDK1.4 users
> to utilize JDK-logging while those preferring log4j or using
> older JDKs can do so as well
Well, we already have one logging abstraction API in the classpath,
so why not use it? The Commons logging abstraction has some
issues relating to automatic discovery--although since we have
simple classloaders we shouldn't have any problems.
I have no problems with using Log4J, although I dislike the
statics that it uses... but that is all over the place in
Jmeter.
There is also another option: Have a central LoggerManager
where we can ask for the Logger implementation depending
on the category name. For Log4J it would create the
Category involved. To switch out the logging implementation
we simply change the LoggerManager instance. It's not that
difficult to do. Who knows, it may be a good way to compare
the relative performance of the logging APIs....
The LoggerManager solution allows us to safely swap logging
packages without trying to ferrit out all the
Category.getCategoryFor("....") calls.
> And finally: Shame on me! I still used "System.out" in
> DurationAssertionGui. I'm going to correct that ;-)
It's done all over the code. I also am to blame for some of
it (i.e. the SSLManager stuff).
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
