Forwarding to the list a message I sent privately to Nicola Ken (didn't notice the reply-to header) that he found interesting for choosing between LogKit and Log4J...
Sylvain -------- Original Message -------- Objet: Re: Refactoring and correction of error notification Date: Thu, 03 Jan 2002 18:14:44 +0100 De: Sylvain Wallez <[EMAIL PROTECTED]> A: Nicola Ken Barozzi <[EMAIL PROTECTED]> Nicola Ken Barozzi a écrit : > >From: "Sylvain Wallez" <[EMAIL PROTECTED]> >> >> Nicola Ken Barozzi a écrit : >>> >>> From: "Sylvain Wallez" <[EMAIL PROTECTED]> >>> >>>> Nicola Ken Barozzi a écrit : >>>> >>>> OK. So I propose system-wide categories. They imply more development in >>>> the Cocoon core, but provide the cleanest way for filtering. >>> >>> +1 >>> If you can work on this, I'll take care of the output part (see below). >> >> I'll make a proposal soon. In order for it to be both speedy and >> available from every place in the code, I think we will need a component >> with a set of static accessor to static loggers. I know static variables >> are a bad thing, but looking up a regular component will certainly kill >> performance. > > Hey, now why not use log4j? > It has static accessors... I don't understand why Avalon made his own version. > It stopped the testlet stuff because JUnit was way ahead, why then not use log4j? > What is needed that it cannot provide? > Ok Mr. Donald, don't hit me too hard on this ;-P I will, but not so hard as Peter or Berin ;) The main thing is about IOC (inversion of control) : a component shouldn't fetch what it needs from its environment, but the environment must give it what it needs. This has several advantages : - security : if no-one has access to your logger, no-one can write fake messages in it. This may seem an integrist approach for logging, but think what happens if the LogTarget sends a SMS to an admin when errors occur in certain categories. Malicious code (e.g. a user XSP) could forbid sleep to your sysadmin ;) - configurability : have you noticed the "logger" attribute that you can place on component declarations in xconf and sitemap ? This allows to manage externally your logging categories. If the category name is hard-coded in the component, you cannot manage the category space. Now about Log4J : some people here started using log4j on some projects, just because "it was known". Since all our projects are cocoon-based, I compared LogKit and Log4J. The results where that Log4J is (I may be flamed for this) badly designed : class names and organization are IMO non intuitive, and more important, logging is *slow* by design compared to what LogKit can achieve. Look for example at Category.callAppenders() : logging an event iterates on all parents of a Category to call the various appenders and each iteration has a synchronized block !!! LogKit on the contrary uses the fact that changing targets occurs less often than logging (if it never happens) and propages targets of a Logger to child Loggers so they have all targets at hand for maximum efficiency. And LogKit also has static accessors : just use Hierarchy.getDefault().getLoggerFor("my.category"). But LogKitManager can prevent this by creating its own hierarchy, not statically available, thus securing it. With this analysis, it was easy to make people switch from Log4J to LogKit ! <snip-all-other-overquoted-stuff/> -- Sylvain Wallez Anyware Technologies - http://www.anyware-tech.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]