https://issues.apache.org/bugzilla/show_bug.cgi?id=46426
--- Comment #5 from Henning Schmiedehausen <[email protected]> 2009-12-13 11:04:36 UTC --- Hi Curt, the main idea of this patch is to start bridging the gap between the various "log<xyz>" implementations. commons-logging was the wrong thing at the right time; these days it seems that slf4j fills the gap nicely. This patch is mainly an exercise in "you can do it, if you really want", not something that should go in tomorrow. Thanks for considering it. -h (In reply to comment #4) > Sorry I missed the bug report last year. Maybe that it was 7 days before my > wedding might explain my mind being otherwise occupied. Just ran across it > doing a routine bug sweep. Surprised that it didn't get more traction when it > was reported. > > The patch has a couple of different aspects, > > 1. Adding Logger.IsErrorEnabled, Logger.IsFatalEnabled, Logger.IsWarnEnabled > > Innocuous additional methods on a concrete class. > > 2. Declaring the Logger implements org.apache.commons.logging.Log and bundling > o.a.c.l.Log > > I'm uneasy about adding the dependency on Logger without providing the class, > don't want to add a new dependency if people are upgrading for unrelated > reasons. However, providing a separate class file would seem likely to result > in the potential for mismatched if o.a.log4j.Logger is cast to a o.a.c.Log > from > a different class loader. > > 3. Providing a concrete implementation of LogFactory. > > I'm uneasy to a log4j.jar that is bundled with some component, but not > actually > used might disrupt a generic LogFactory that is dispatching to some other > logging framework. > > My gut is it might be better for log4j to conditionally implement > o.a.common.Log is it available, but not provide it. Maybe: > > o.a.l.Logger gets the three extra methods. > Create another class (CLogger for the rest of the discussion) that extends > o.a.l.Logger and implements Log. > Default log4j factory would attempt to create the CLogger's but if they > encounter a ClassNotFoundException, they'd create plain Loggers. > The Common Logging adapter for log4j could do an instanceof on the loggers > returned from log4j and if they supported Log then pass them directly to the > caller, otherwise wrap them as previously. > A hard-coded LoggerFactory wired to log4j could be provided as an extra jar. > > > I'd love for you to update the report with your current thoughts. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
