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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- 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]
