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]
