commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Probst" <andpr...@gmx.net>
Subject Re: [logging] LogConfigurationException
Date Fri, 06 Jun 2003 19:44:14 GMT
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 <andpro77@gmx.net>
> > Reply-To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
> > To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
> > 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: afelber@austin.rr.com
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 



Mime
View raw message