As I understand it, the current *implementation* in Ant of event-based model for logging does NOT fully take advantage of one of log4j's most important advantages, that is, its ability to process and filter messages by logger name. This can be attributed partially to the way Log4jListener is implemented. In this regard, CommonsLoggingListener is a better implementation for the event-based model for logging. The CommonsLoggingListener .messageLogged() method at least makes an effort to use a logger name which matches as closely as possible the component generating the log message.
I think the monitor approach applies in case:
1) logging is not an important concern,
For example if
At 02:13 PM 1/10/2005, Vincent Massol wrote:
That's funny because I've always thought the opposite: for Cargo for example, we are offering a Java API that is meant to be embedded and the reason I have developed the monitor is specifically to avoid dragging another dependency (which does not provide visible business value to the user). What it is doing is pushing the logging definition to the user (if he wants to be concerned about logging). So in my opinion the monitor is really best when you wish your code to be embedded.
Cactus is in between: it's not really embeddable although it could be considered like embeddable in the sense that a Cactus tests can be run in any existing JUnit Test Runner. However, when you use Cactus with our Ant tasks or the Maven plugin, it becomes an application. I believe this represents the main usage.
Thanks -Vincent
-- Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
