Re: DOMConfigurator can't see my class

[Paul Glezen <pg...@atdial.net>]

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

Re: DOMConfigurator can't see my class

[Alan Robertson <ar...@mail.infonow.com>]

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