commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [logging] LogConfigurationException
Date Thu, 05 Jun 2003 06:41:48 GMT


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
>
>

Mime
View raw message