The context class loader of AWT event dispatch threads is being set to
the system class loader instead of the applet class loader. This causes
callback methods that use subsystems that depend on the thread's
context class loader (such as RMI and JNDI) to not find classes as expected.

This worked in JDK 1.2.1 but seems to have regressed in JDK 1.2.2 and Kestrel-beta. 

Here's the analysis by Peter Jones:

PRIOR to the fix for 4189625, an applet's AWT-event dispatch thread was
created from within the applet's applet-event dispatch thread (before it
enters the applet-event processing loop).

The applet-event loop is executed by sun.applet.AppletPanel.run().
Notice the following piece of code near the beginning of that run()
method in SCCS delta 1.75 of AppletPanel.java (right before 4189625 was
fixed):

	// Create an AppContext for this ThreadGroup
	appContext = SunToolkit.createNewAppContext();
	appContext2ThreadGroup.put(appContext, curThread.getThreadGroup());

The call to sun.awt.SunToolkit.createNewAppContext() ends up creating
the AWT-event dispatch thread from the current thread because it
constructs a new java.awt.EventQueue, which, in turn, constructs a new
java.awt.EventDispatchThread, which is the thread object that AWT
events will be dispatched in for the applet associated with this
AppletPanel.

And since the applet-event dispatch thread gets its context class
loader set to the applet's class loader in
AppletPanel.createAppletThread(), the AWT-event dispatch thread created
from within it will inherit that context class loader, and applet code
executing AWT callbacks will have their own class loader as the context
class loader.

SUBSEQUENT to the fix for 4189625, an applet's AWT-event dispatch
thread is created directly (or at least more directly than before) from
within AppletPanel.createAppletThread(), so the context class loader is
no longer inherited from the applet-event dispatch thread.

When AppletPanel.createAppletThread() calls loader.grab(), this invokes
AppletClassLoader.getThreadGroup(), which creates the applet's thread
group *and* creates a "AppContextCreator" thread in that thread group,
whose run() method calls SunToolkit.createNewApplet(), which ends up
constructing the EventQueue and thus the AWT-event dispatch thread.

The above AppContextCreator thread ends up inheriting its context class
loader from the thread that called createAppletThread()-- the
applet-event dispatch thread hasn't even been started (or even had its
context class loader set) yet-- so that is also the context class
loader inherited by the AWT-event dispatch thread created within.  This
loader will be the system class loader, not the applet's class laoder.

Well, that's what I think has caused the change, but what can we do
about it?

One solution that quickly comes to mind is to have the
AppletClassLoader.getThreadGroup() method set the context class loader
of the AppContextCreator creatorThread to >itself< before starting that
"creatorThread".  This fix would be particularly convenient because
there is already a doPrivileged() block (with an anonymous inner class)
for creating this AppContextCreator thread anyway, so it wouldn't
require another one to set its context class loader.  With this change,
the AWT-event dispatch thread created for a given applet will have the
applet's class loader as its context class loader, as we would like.