syslog vs. log4j

[Henrique Seganfredo <he...@neogrid.com.br>]

I got this from
http://www.javaworld.com/javaworld/jw-04-2001/jw-0427-letters.html

(ok, I did not work with syslog, but I could not understand why syslog in
the author´s viewpoint is better...all features claimed to syslog do happen
in Log4j!)

------------------------------------------------------------------------

Logging Systems 
'Robust event logging with Syslog'
Nate Sammons 


How does Syslog compare with Log4J? 


Nate, 

Syslog sounds nice, but why should I use Syslog and not Log4J. Is Syslog
better than Log4J? How is Syslog different? 

Geert Mergan 

Geert, 

First, I want to say that Log4J is, as far as I know, a good product. 

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. 

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. 

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. 

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. 

At their hearts, Log4J and Syslog want to do basically the same thing -- log
messages in a flexible way and not interfere with coding and performance. 

Nate Sammons 

Re: syslog vs. log4j

[Paul Glezen <pg...@atdial.net>]

I don't have a problem with sending my response to the Java World
folks.  The only concern I would have would be that of creating the
false impresssion that there is a "Logging Battle" going on between
log4j and syslog.  

Granted, his remarks concerning log4j were not very accurate.  Perhaps
he hadn't looked at log4j in a while.  (This is entirely reasonable. I
prefer log4j over jlog and yet I haven't given jlog or syslog an honest
look in almost a year.)

Having said that, it is only a response to a response to a question.  It
hardly constitutes a flame war.  I will read the original article first
to make sure nothing in my note gets written out of context.

- Paul
-- 
Beware of bugs in the above code.  I have
only proved it correct, not tried it.
-Don Knuth

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org

Re: syslog vs. log4j

[Ceki Gülcü <cg...@qos.ch>]

Paul,

You should send this to Java World letters to the editor as a reply to Nate Sammons. Nate's original comment can be found at http://www.javaworld.com/javaworld/jw-04-2001/jw-0427-letters.html. The e-mail adress is jweditors@javaworld.com  

Regards, Ceki



At 08:30 18.05.2001 -0700, you wrote:
>> 
>> 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: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org

--
Ceki Gülcü


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org

Re: dumping log4j configuration [WAS: syslog vs. log4j]

[Anders Kristensen <ak...@dynamicsoft.com>]

Paul Glezen wrote:
> 
> > 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.

It's a done deal. Up to a point, anyway. Have a look at PropertyGetter
and PropertyPrinter in org.apache.log4j.config as well as
PrintProperties in the test package. The two former classes together
provide support for dumping the current log4j configuration to a
properties config file.

It cannot handle all aspects of config files, especially not some of the
more advanced features which are in the DOMConfigurator and not the
PropertyConfigurator. Also, there's currently no way of generating an
XML config file, only properties file.  I was planning on adding some of
those missing parts and then use them to write a small transcoding
utility which would translate between different config formats simply by
using one configurator to to configure log4j in teh usual manner and
then use a "config writer" for outputting the current log4j
configuration in a different format (or the same as a way to get
pretty-printing, maybe).

I was (am, when I find the time) going to use this feature as part of
way to have a console tool connect to a running JVM with log4j
configured. The console would connect, retrieve the current
configuration, set up a new hierarchy of its own with the configuration
retrieved from the other guy (possibly massaged somehow), and then have
other guy add a SocketAppender at select points in it's configuration
hierarchy. This would allow the console to receive logging data and
render it just like it's rendered by the "other guy". Sounds like fun,
no?

Cheers,
Anders

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org

Re: syslog vs. log4j

[Paul Glezen <pg...@atdial.net>]

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

xml configuration

[Jochen Kramer <kr...@thales.de>]

hey,

i'm trying to use the xml configured log4j logging. 
after writing the .xml file, like given in sample, i just set the
log4j.configuration system property and hoped for the DOMConfigurator. 
But i always get a no appender could be found for this category error
log. 

is there something special to do, in any order, to use the xml based
configuration?

jck

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org