On Thu, 5 Jun 2003, Andreas Probst wrote:
> Date: Thu, 05 Jun 2003 07:09:48 +0200 > From: Andreas Probst <[EMAIL PROTECTED]> > Reply-To: Jakarta Commons Users List <[EMAIL PROTECTED]> > To: Jakarta Commons Users List <[EMAIL PROTECTED]> > Subject: Re: [logging] LogConfigurationException > > Having read the two articles > > http://www.qos.ch/logging/thinkAgain.html > https://secure.zdnet.com.au/builder/program/java/story/0,20000347 > 79,20272367 ,00.htm > > I think it's better not to use Commons-Logging in my app and > certainly not within the test cases. Maybe I should use it in > components which could be reused... > > Craig, what do you think about the first article? I think two things about this article, and then have some additional comments: * Ceki Gulcu is an incredibly brilliant person, who (pretty much) created Log4J -- a very useful logging implementation that has some unique and powerful capabilities. Those capabiliites have been created in direct response to requests from users, in the best traditions of open source software. * Ceki Gulcu, as the primary author of Log4J, justifiably argues for its viability. So anything he says about, say, JDK 1.4 logging, needs to be understood in that context. However, the primary focus of these articles (a comparison of Log4J versus JDK 1.4 logging) is pretty much irrelevant to the customers of most Jakarta Commons libraries. Why? Because the Jakarta Commons libraries that use commons-logging insulate applications using them from having to choose one logging implementation or the other. NOTE CAREFULLY that you can easily use a Jakarta Commons package -- even one that uses logging -- secure in the knowledge that using that Commons package does not force *you* to use the same logging implementation that the authors of that particular library happened to pick. Permit me to spend a few pargraphs venting on this topic ... :-) The fundamental issue that causes grief, here in the Commons world, has nothing to do with Ceki, or even with Log4J (or even any argument about whether Log4J or JDK 1.4 logging is technologically superior). The real problem is that some people expect that commons-logging is something that it is not. The really important issue: The commons-logging package ***IS*** a facade around a variety of logging implementations, so that a library using it (say, commons-digester just as an example) does NOT dictate the logging implementation that an application using Digester has to use. That is the one and only purpose for which it was created. And the fact that the Digester developers made the choice to use C-L (disclaimer: I'm one of those developers :-) was a positive step towards making that package reusable in more contexts, but not giving up the benefits that embedded logging statements can bring. The commons-logging package ***IS NOT*** a logging implemntation itself (other than the fact that it includes a fallback SimpleLog implementation which, in retrospect, might not have really been a good idea because of the confusion that has resulted). It expects that the underlying application will have picked whatever logging implementation is appropriate, and done its own configuration of that logging environment, totally independently of commons-logging. A clue that you get it -- you understand that changes in the underlying logging implementation automatically affect libraries that use commons-logging, without requiring *any* changes in those libraries. The only thing C-L knows is the *name* of a "logger", not where the output of that logger is configured to go. A clue that you don't get it -- you expect that o.a.c.logging.Log instances should themsleves be configurable as independent entities (they are supposed to be *invisible* facacdes around the actual logging entities). Or, you expect that commons-logging will provide an API to transparently configure, and reconfigure, the underlying logging implementation. Or, that C-L should provide a mechanism to deal with application-level facades (in spite of the fact that C-L is already a facade, and goes to great lengths to hide itself). That is not what commons-logging is for. What commons-logging is for, is to allow a function library, such as a library you might choose from Jakarta Commons, to be able to use logging in its own implementation classes, *without* creating a prerequisite that the application using that libarary must use the same logging implementation that the library developers happened to like. PLEASE DO use commons-logging in your applications where you don't want your application to be directly tied to a particular logging implementation. As an example of this scenario, Struts (an MVC framework for web applications) uses C-L so that it does *not* force an application developer to choose whatever logging implementation that the Struts developers happen to like. PLEASE DO NOT use commons-logging on the theory that you will be able to portably configure, for example, the "foo.bar" logger to be at DEBUG level of detail, while the "foo.baz" logger is at the WARN level. That is outside the scope of commons-logging. You are only going to end up frustrated. > > Regards, > > Andreas > Craig PS: The exception message described in the message below is *absolutely* and *positively* related to screwing up the class loader hierarchy of the test environment, and has nothing to do with commons-logging as such (unless they are using a verson of C-L before 1.0.3, all of which still had some class loader issues). Most likely, the tester has exposed the C-L classes in more than one class loader (a class "foo.bar" loaded from class loader A is not considered to be the same as class "foo.bar" loaded from class loader B -- even if the bytecodes happen to be the same) -- that is pretty much guaranteed to cause fatal problems, no matter what particular classes you are trying to load. PPS: Specific note to Andreas -- make sure that you are using Commons Logging 1.0.3, and also make sure that you are executing your tests in a separate JVM so that you don't get messed up by the CLASSPATH that was specified on your Ant execution. > > On 4 Jun 2003 at 8:03, Andreas Probst wrote: > > > Thank you both Achim and Anthony for your replies. > > > > I still can't get it to work. Achim, I tried your code - and it > > works. Then I commented the junit-call out of the main method - > > and it works. > > > > public static void main(String[] args) > > { > > //BasicConfigurator.configure(); > > logger.debug("test"); > > junit.swingui.TestRunner.run(AllTests.class); > > } > > > > If I run the code above, the "test" gets logged as expected, but > > after that the exception below is thrown. > > > > Is there a known issue with JUnit 3.7? > > > > log4j: Finished configuring. > > 04 Jun 2003 07:50:21,122 DEBUG AllTests: test > > Exception in thread "main" java.lang.ExceptionInInitializerError > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > > Method) > > at > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorI > > mpl.java:39) > > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodA > > ccessorImpl.java:25) > > at java.lang.reflect.Method.invoke(Method.java:324) > > at > > junit.runner.BaseTestRunner.getTest(BaseTestRunner.java:111) > > at junit.awtui.TestRunner.runSuite(TestRunner.java:455) > > at junit.awtui.TestRunner.start(TestRunner.java:536) > > at junit.awtui.TestRunner.main(TestRunner.java:382) > > at junit.awtui.TestRunner.run(TestRunner.java:387) > > at de...AllTests.main(AllTests.java:29) > > Caused by: org.apache.commons.logging.LogConfigurationException: > > org.apache.commons.logging.LogConfigurationException: > > org.apache.commons.logging.LogConfigurationException: Class > > org.apache.commons.logging.impl.Log4JLogger does not implement > > Log > > at > > org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFac > > toryImpl.java:532) > > at > > org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFac > > toryImpl.java:272) > > at > > org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFac > > toryImpl.java:246) > > at > > org.apache.commons.logging.LogFactory.getLog(LogFactory.java:395) > > at de...AllTests.<clinit>(AllTests.java:21) > > ... 10 more > > Caused by: org.apache.commons.logging.LogConfigurationException: > > org.apache.commons.logging.LogConfigurationException: Class > > org.apache.commons.logging.impl.Log4JLogger does not implement > > Log > > at > > org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor( > > LogFactoryImpl.java:416) > > at > > org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFac > > toryImpl.java:525) > > ... 14 more > > Caused by: org.apache.commons.logging.LogConfigurationException: > > Class org.apache.commons.logging.impl.Log4JLogger does not > > implement Log > > at > > org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor( > > LogFactoryImpl.java:412) > > ... 15 more > > > > Andreas > > > > On 2 Jun 2003 at 22:50, Achim Felber wrote: > > > > > Andreas, > > > > > > I think Anthony might be right; you could be using incompatible versions > > > of Log4J and commons-logging. Below is an application that worked for me. > > > Make sure Log4J finds its configuration file. The debug switch can be quite > > > helpfull too. ;-) > > > > > > Regards, > > > Achim > > > =========================================================== > > > import org.apache.commons.logging.*; > > > import org.apache.log4j.*; > > > > > > public class LogTest > > > { > > > public static void main(String[] args) > > > { > > > LogFactory.getLog("TestLog").debug("Seems to work ...!"); > > > } > > > } > > > > > > // java -Dlog4j.debug=true -Dlog4j.configuration=file:/c:/data/sort4.properties > > > LogTest > > > > > > On Mon, Jun 02, 2003 at 01:58:27PM -0400, Anthony Eden wrote: > > > > You can also put the log4j.properties file in a location which is known > > > > to Log4J. Take a look at the Default Initialization Procedure section > > > > in the short manual ( http://jakarta.apache.org/log4j/docs/manual.html ) > > > > for information on how Log4J attempts to find the properties file. > > > > > > > > As for the specific problem, make sure you are using both the current > > > > version of Log4J and the current version of Commons Logging. Also, > > > > check your whole classpath for other copies of either Commons Logging or > > > > Log4J. > > > > > > > > Sincerely, > > > > Anthony Eden > > > > > > > > Andreas Probst wrote: > > > > >Hi Achim, > > > > > > > > > >thank you for your answer. You're right - I would have to change > > > > >the configuration only once. It's not what I expected, but OK, I > > > > >think I can live with it. > > > > > > > > > >However, putting an > > > > >BasicConfigurator.configure(); > > > > >into the main() method doesn't solve the current problem: > > > > > > > > > >Caused by: org.apache.commons.logging.LogConfigurationException: > > > > >org.apache.commons.logging.LogConfigurationException: > > > > >org.apache.commons.logging.LogConfigurationException: Class > > > > >org.apache.commons.logging.impl.Log4JLogger does not implement > > > > >Log > > > > > > > > > >Does anyone have a clue there? > > > > > > > > > >Regards > > > > > > > > > >Andreas > > > > > > -- > > > Achim Felber > > > e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > > --------------------------------------------------------------------- > 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]
