avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: Question on LogKit
Date Wed, 20 Jun 2001 08:38:12 GMT
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.

> > 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.

> > 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 

> > 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

> 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. 

The only thing that I am aware that I "copied" from Log4j was some names. 
When LogKit went from alpha->beta I changed the following names to align with 
Log4j terminology.


This was at the request of some Log4j users. The only actual feature that I 
have considered copying is the concept of ErrorHandler - however as yet that 
hasn't been implemented as there has been no demand.



| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

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

View raw message