avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <...@qos.ch>
Subject Re: Question on LogKit
Date Wed, 20 Jun 2001 09:36:12 GMT
At 18:38 20.06.2001 +1000, Peter Donald wrote:
>On Wed, 20 Jun 2001 18:12, Ceki Gülcü wrote:
>> On Wed, 20 Jun 2001 13:38:54 +1000 Peter Donald wrote:
>> > > The Logging JSR also has some good points - two of the best is that it
>> > > has far superior naming semantics and that it is a standard.
>> JSR47 does not have far superior naming semantics. 
>Guess thats a matter of opinion. I prefer to log to a logger - which is a far 
>better semantic notion IMO - in reality clients don't even need to know that 
>Loggers are associated with categorys/channels/subjects.
>> > LogKit is different in that it does not attempt to cover the breadth
>> > that the other two toolkits try to do. LogKit does not attempt to do
>> > localisation (that should be done in another part of API IMHO).
>> It looks to me that LogKit does the same as the other two APIs. Why don't
>> you call a cat by its name?
>Velocity, XSP and JSP all do the same thing aswell. They have different 
>strengths and weaknesses whichs is why people like the choice.

As far as I know, Velocity and Turbine wrap log4j. I do not know about XSP. There are two
tag libraries that give JSP pages access to log4j functionality.

>> > It is also "Secure" by default. Where Log4j allows you to access parent
>> > of current Logger/Category - LogKit does not. Thus Log4j would allow any
>> > child you pass a Category to modify any logger in whole tree (thus it
>> > could choose to shutdown logging of authentication module just before
>> > doing some nasty stuff etc). It also protects root logger behind facade
>> > (So as to avoid any funny buisness).
>> What kind of attack do you have in mind? What does security have to do
>> with child/parent relationship? Can you please expand?
>See above and the other responses I have made to you in past.

Yes, I have responded to you in a separate email message.

>> > LogKit also does not provide support for passing in "source" of logging.
>> > Both Log4j and JDK Logging allow you to specify "this logging message
>> > came from class foo". This is of course error prone and insecure. Log4j
>> > has it slightly better in that it can also autodetect caller but this is
>> > expensive operation.
>> Really? This is certainly news to me. Exactly which log4j class and method
>> allow the user to specify the source of the caller?
>Category.log(String callerFQCN, Priority priority, Object message, Throwable 

The callerFQCN parameter is a hint given by sub-classes or wrappers of the Category class
to allow the correct extraction of caller localization. I hope we got this one cleared up.

>> > So I guess the main difference between LogKit and others is that LogKit
>> > is faster, lightweight and does not support insecure or poor logging
>> > practices.
>> Can you substantiate your claims with hard figures? In what way is
>> LogKit faster, smaler, better, smarter...?
>* Samller as has less classes, less lines of code etc.
>* Faster as last time I tested it Log4j was slower (mainly as it did dynamic 
>lookups of things and has bunches more logic in dispatching that is not 
>inline friendly). 
>* better IMO because of above two points combined with better security design

This is from http://jakarta.apache.org/log4j/docs/critique.html


Logging performance must be studied in three distinct cases: when
logging is turned off, when turned on but due to priority comparison
logic not enabled, and when actually logging. Please refer to the
log4j manual for a more detailed discussion of logging performance.

When logging is turned on, log4j will be about three times slower to
decide whether a log statement is enabled or not. This is due to the
dynamic nature of log4j which requires it to walk the hierarchy. To
give you an idea about the figures involved, we are talking about 90
nanoseconds instead of 30 nanoseconds on a 800Mhz Intel processor. In
other words, one million disabled logging requests will cost under a
second in both environments.

In a shipped binary, you can turn off logging entirely and both APIs
will perform identically. Note that if one is not careful, the cost of
parameter construction before invoking a disabled log statement will
overwhelm any other performance consideration. Regardless of the API
you decide to use, logging statements should never be placed in tight
loops, for example, before or after an element swap instruction in a
sort algorithm.


Yes, LogKit is faster in certain cases. In shipped code, when logging
is turned off entirely, log4j is just as fast. In other cases, it is
slower but in the nanosecond scale. In compensation log4j offers 
powerful inheritance features. 

>> You have chosen to continue to develop LogKit because you think you
>> can do a better job. That is your prerogative. In the process, you
>> have copied from log4j without contributing back. I do not think this
>> honors you. We innovate, you copy. This is similar to what Sun is
>> doing except that they do it at a slower pace. You do it from the
>> inside which makes it all the more aggravating.
>Thats an interesting perspective. I seem to remember a few features that 
>Log4j aquired that look remarkably similar to features in LogKit. I am 
>willing to bet that Log4j doesn't have my name in credits anywhere. 

What acquired features are you referring to? I have never ever used 
the work of others without permission. I confess that most of the 
innovations in log4j were contributed by the log4j community, not by me.

Anyone, including you, Peter, is welcome to contribute to the log4j 
project. We need all the talent we can get. Regards, Ceki

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

View raw message