FWIW, both Log4j 1.x and Commons Logging were implemented before JDK 1.4 when Java logging was introduced. I have been told the JDK spec writers spoke to Ceki (a significant contributor to Log4j 1.x) and mostly ignored what he advised them to do. As a consequence SLF4J, Logback and Log4j 2 all exist because it was felt that the JDK implementation is insufficient.
Ralph > On Jan 5, 2015, at 8:00 AM, Shawn Heisey <[email protected]> wrote: > > On 1/5/2015 7:09 AM, Goran Karlic wrote: >> I looked into SLF4J - it seems an overkill for the situation: around 95% of >> logs are JUL, maybe 5% log4j. >> >> Adding multiple SLF4J jars for that 5% with their overhead is not really an >> option -- But I'll think about it anyway, since it seems the only "fair" >> solution. >> >> I'll ask the dev of that module to switch from log4j to JUL, seems the >> simplest solution (never would have thought that before - but one can always >> learn :-) > > From the code side, I'm really only familiar with slf4j, but I would > imagine that if the developer is using log4j, they would consider JUL to > be a major step backwards and will not want to do it ... but they MIGHT > be willing to switch to slf4j. With slf4j, the developer (and in some > cases, like with Solr, the end-user) can easily change the final logging > endpoint to whatever framework they like best, without changing the code > at all. > > From the user side, I find log4j's configuration to be a lot more > flexible than JUL. I have never looked into the performance. Putting > forth a conjecture: if the performance and flexibility of the logging > built into Java were good enough, I don't think that Apache would have > bothered with two of their own systems for logging -- log4j and the > logging subproject under commons. > > Thanks, > Shawn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
