logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Robertson <arobert...@mail.infonow.com>
Subject Re: DOMConfigurator can't see my class
Date Mon, 02 Apr 2001 20:45:22 GMT
Well, I finally figured out this problem and will pass on the solution for anyone who's interested.

This is what I think was happening:  I had dropped the Log4J jar files into my 'ext' directory
and so I
assume the extension classloader was loading the Log4J classes.  So when it came time for
the DOMConfigurator
to find my version of the PatternLayout class, the extension classloader was the one trying
to find that
class.  The problem is that I needed the application classloader to be the one doing that.
 So I just took
the Log4J jar files out of the 'ext' directory, put them in another directory and then added
them to my
classpath setting in my IDE.  After that, the DOMConfigurator had no problem finding my modified
pattern
layout class.

Paul, thanks for the pointer that eventually helped me figure this out.

Alan

Paul Glezen wrote:

> Alan Robertson wrote:
>
> > Ok, now I know the first thing you're thinking is "check your
> > classpath".  Well, I've done that.  I've tried including every possible
> > directory I can think of in my classpath and nothing helps.  Now, to add
> > another twist on this problem, if I jar up my class files and drop that
> > jar file in the 'jdk1.2.2/jre/lib/ext/' directory, then DOMConfigurator
> > can find that class of mine.  So why can that class be found if it's in
> > a jar in the 'ext' directory, but not in the classpath?  Any suggestions
> > would be appreciated.
>
> Hi Alan,
>
> What you're seeing makes sense.  Remember that there are three class
> loaders involved in any Java 1.2 app
>
>   1. Boot classloader (boot)
>   2. Extension classloader (ext)
>   3. Application classloader (app)
>
> The boot is the parent of the ext, which in turn is the parent of the
> app.  When you place your log4j jar in the extension directory, you
> cause the log4j classes to be loaded by the ext classloader.  If you
> have your log4j extensions outside of the extension directory, then it
> is likely loaded by the app classloader.  Child classloaders usually
> delegate to the parent before attempting to load a class; but not
> vice-versa.
>
> For some good general info on classloaders, check out the link below.
> It's oriented toward WebSphere's app server.  But the first 10 pages are
> purely concerned with classloaders themselves.
>
> http://www7.software.ibm.com/vadd-bin/ftpdl?1/vadc/wsdd/pdf/gisell/UnderstandingWebSphereClassLoaders.pdf
>
> - Paul
> --
> Beware of bugs in the above code.  I have
> only proved it correct, not tried it.
> -Don Knuth
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org


Mime
View raw message