jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject RE: Log4j integration testing with Application Servers
Date Tue, 11 Jan 2005 11:49:20 GMT

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.

Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/

View raw message