These two loaders I believe should be the same by default, but there is
a method in Thread to set the thread context class loader directly. This
can help as workaround when the user classes must be loaded from some
other place. For instance, when we run Mauve test, the system class
loader = default context class loader = loader, used to load the
application is the loader who started the Ant. It will not load any test
class by name because these are loaded by the custom Ant class loader.
To get the test work, I obtain the class loader of the testlet and
temporary set it as a context class loader for the thread that enters
the Testlet.test. Then Thread.getConextClassLoader() in the testlet
returns the correct loader, even if called from another thread,
constructed inside the Testlet.test.
I would suggest to think twice before using Class.forName in the core
class. Class.forName there means "use the loader of the current class" =
"use system class loader". And the system class loader only knowns about
GNU Classpath classes and about nothing else.
Sun's CORBA somehow manages to find classes that are not visible by both
system and context class loaders, but are present in the execution
stack. I was only able to implement the same with the help of
VMStackWalker, as it was suggested by Jeroen.
Tom Tromey wrote:
"Audrius" == Meskauskas Audrius <[EMAIL PROTECTED]> writes:
Audrius> getSystemClassLoader returns the different loader that
Audrius> has loaded the application, same as the default
Audrius> Thread.getConextClassLoader() that I would use in this case.
We have a few PRs in this area. What we need are test cases to
determine whether the system or context class loader ought to be used.
Tom
_______________________________________________
Classpath-patches mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/classpath-patches
