Hi Craig, thank you very much for your comprehensive response. However, I did not manage to get it running with my test setup. I suppose it's because of the architecture of the graphical UI's in JUnit. I stick to log4j at least within my tests.
Thanks again. Andreas On 4 Jun 2003 at 23:41, Craig R. McClanahan wrote: > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
