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 08:12:51 GMT

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. It just has
different names for the same things. JSR47 is a standard because it is
promulgated by Sun. Log4j is a de facto standard because it is used by
thousands developers who also happen to like it.

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

> 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?
 
> 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?
 
> LogKit also does not encourage accessing Loggers via statics (where both 
> other APIS mandate it etc).
> 
> 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...?
 
> > Are logKit and log4j competing code bases?
> 
> yes and no. Yes because they both do logging, no because they have fairly 
> different performance and design characteristerics.
> 
> > is one gonna use the other in the (present) future?
> >
> > is there plans for developing one and decomissioning
> > (or do maintainance only) over the other?
> 
> Unfortunately not. I tried to get Ceki to cooperate but it wasn't meant to be 
> ;)
>  

Peter, log4j is an API that is used by thousands of developers. We
cannot break backward compatibility just to please you. There is more
to development than haggling over class names. If you have a new and
innovative concept to contribute to log4j, then we will gladly
incorporate it, giving you all due credit, including commit access.

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.

Regards, Ceki

ps: For details on the JSR47 vs. log4j controversy please see
http://jakarta.apache.org/log4j/docs/critique.html. 


--
Ceki Gülcü


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


Mime
View raw message