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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
