>
> I think that Syslog has a simpler API for writing messages. In Log4J,
> you have to retrieve an instance of a Category object before you can
> log, like this:
>
> Category cat = Category.getInstance("com.foo");
> cat.info("Here is a message");
>
> With Syslog, you just call static methods:
>
> Syslog.info("Here is a message");
>
> Categories in Log4J are roughly equivalent to channels in Syslog. They
> can both be used to route messages.
It seems that Syslog prefers to use static methods over instance methods
for logging. This has the short-term advantage of using a globally
defined function that does not require a prior instantiation. The
drawback to this approach is that there is no potential for
polymorphism. If I want to extend the Syslog class with my own
"catagory" (or whatever they call them), I cannot override the info
method. I can declare it, and call it explicitly, but not
polymorphically.
> I think Syslog's configurations are more flexible. With Syslog, you
> can modify a running configuration and ask it to write its
> configuration out to an XML file to be read in later.
Cool. I belive log4j's config mechanism is quite flexible. One can
also change it programmatically at runtime. I don't believe log4j will
write a property/xml file with the currently running configuration. We
might consider doing that some time if anyone wants to code it. It
would be a nice feature.
> In addition, Syslog has more loggers. It includes loggers that write
> to output streams (like System.out), regular files, files that rotate
> before they grow to a certain size, and files that rotate every hour
> (or minute, week, or month). It also includes loggers that write to
> Java Message Service, Remote Method Invocation, databases, and to a
> logger that sends email (text or HTML). That being said, writing your
> own logger is as simple as implementing an interface, and common
> functionality is inherited from the base logger class that comes with
> Syslog.
This is nothing over log4j. As far as I know, it does all of that
except perhaps the RMI appender. Appenders are perhaps the most
personal aspects of a logging tool in that most everyone has their own
idea of which appenders are important. For this reason, it is critical
that existing appenders be extensible and new completely different
appenders be easily added. The log4j source distribution includes a
contribution section made from many people who use log4j. Almost all
the contributions are new kinds of appenders.
>
> Syslog's log policies allow extremely fine-grained use. Let's say that
> you log everything on all channels at the WARNING level or above. If
> you have problems with one particular object, you can add a logger at
> runtime that singles out that object -- by class name or a pattern of
> class names, which is good for selecting a package -- and logs
> everything coming from that object to a separate log.
Log4j does this as well. From my understanding, it's what using multiple
categories is all about.
- Paul
--
Beware of bugs in the above code. I have
only proved it correct, not tried it.
-Don Knuth
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
