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 12:14:02 GMT

Sorry, my last message went off prematurely. Here is the complete one.

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) Your application model is so tight and well-defined that you can
reduce most log messages into few event types, and those that do not
fit into those event types can be deferred to a default catch-all type
without too much prejudice, e.g. Ant being the prime example.

2) logging is not an important concern,

For example, if you don't really care about the capabilities offered
by modern logging systems. Your application generates relatively few
log messages and the end-user should be able to sift through them
without too much pain.

3) Reducing the number of dependencies is important

In the long run, I think sticking to the standard approach pays off
handsomely. You don't need to define a special events and interfaces
for propagating logging messages. Most importantly, your code can
generate any log message it wants, even those that don't fit into the
model.

In the long run, I think sticking to the standard logging approach
pays off handsomely.  You don't need to define special events or
interfaces for propagating logging messages. Just as importantly, your
code can generate any log message it wants, even those that don't fit
into the model. I believe the standard approach to be less intrusive
and imposing (except for the jar dependency). On the other hand, if
you see logging mostly as a nuisance, then the monitor approach helps
to keep logging constrained in a corner, which is not necessarily bad
in itself.

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
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cactus-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: cactus-user-help@jakarta.apache.org

-- 
Ceki Gülcü

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



Mime
View raw message