Nicholas Lesiecki wrote:
>
> Timothy,
>
> that's one of the best descriptions of this common problem I've seen. We're
> using the Thread.getContextClassLoader() method in 1.3 to give cactus a
> little more flexibility about which class loader it uses. I'm not sure it
> would have solved your issue, but hopefully it will make this problem less
> frequent.
You're right. Thread.getContextClassLoader() would not help in this
case since it will actually return the same classloader that
Class.forName() would end up using anyway. Where
Thread.getContextClassLoader() does help is when the classes doing the
dynamic loading are higher in the classloader hierarchy, such as
standard extensions. If they were to use the Class.forName() approach,
their classloader would be used, and they would only be able to load
things from the same classloader or a higher one.
> Do you mind if we harvest your mail for inclusion in the FAQ?
By all means, feel free to include it in the FAQ.
- Tim
>
> Cheers,
>
> Nick
>
> -----Original Message-----
> From: Taylor,Timothy L. [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 13, 2002 1:59 PM
> To: Cactus Users List
> Subject: Re: NoClassDefFoundError Again
>
> Keith,
> I ran into a similar problem, I think. My problem was that the
> ServletRedirector class seemed to be finding my test class, but I was
> getting a NoClassDefFoundError for the SerlvetTestCase class.
>
> When I finally tracked the problem down, I found that it was caused by
> the fact that there is a hierarchy of class loaders, and the class
> loaders can only see classes loaded from their level or higher in the
> hierarchy.
>
> This is what my class loader hierarchy looked like:
>
> 0: The JVM bootstrap class loader
> 1: Standard Extension class loader
> 2: Application class loader (classes defined in CLASSPATH env var)
> 3: App server classes class loader
> 4: App server lib class loader (for extensions to app server)
> 5: EJB class loader serving all of the EJB jar files defined in my EAR
> 6: WebApp class loader serving all jar files in WEB-INF/lib and all
> classes in WEB-INF/classes
>
> The ServletRedirector class is loaded by class loader #6 in my case.
> When it was doing a Class.forName(my.test.class), my test class was
> being found by the class loader #5 (and #6 as it turned out), but the
> one from #5 is found first since #6 defers to it's parent (#5) first and
> only checks its managed classes if it isn't found by the parent. Since
> class loader #5 found my test class, it also tried to loaded the
> dependencies (the cactus ServletTestCase). Since ServletTestCase lives
> in cactus.jar served by loader #6, loader #5 can't see it and was
> throwing the NoClassDefFoundError.
>
> The solution was to make sure that all test cases (and dependant
> classes) are visible from the class loader serving the cactus.jar file.
> It was easy in my case since the fact that my test case was packaged in
> one of the EJB files was a mistake :-)
>
> - Tim
>
> [EMAIL PROTECTED] wrote:
> >
> > I have an ear file which contains an ejb jar file and a war file. We keep
> > utility classes in the ear file since the classloader for the war will
> find
> > classes in the ejb jar (at least on WebLogic 6.1). When I compile the ear
> > for my test case I put the servlet entries in my web.xml for the
> > ServletRedirector however; it doesn't not find the test class when it is
> in
> > either the ejb.jar or the war file. It only finds it if I explicitly set
> > it in the system classpath for the startup of weblogic. I have seen
> > references to the fact that junit uses its own classloader. Is this true
> > and if so could it be causing my problem?
> >
> > Thanks,
> > Keith
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
