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 t); > > 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. LogEntry->LogEvent LogEngine->Hierarchy 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. Cheers, Pete *-----------------------------------------------------* | "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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
