[RFC] plugin: use an AppContext to support applets running with different look and feels

[Omair Majid]

On 10/14/2010 02:34 PM, Deepak Bhole wrote:
> * Omair Majid<omajid at redhat.com>  [2010-10-14 14:17]:
>> On 10/07/2010 05:33 PM, Omair Majid wrote:
>>> Hi,
>>>
>>> The attached patch is an (updated) attempt to fix PR565 [1]. The patch
>>> does two things:
>>>
>>> 1. It creates a ThreadGroup for the applet earlier in the initialization
>>> phase.
>>>
>>> The applet's intialization code (currently) creates 3 threads (most of
>>> this code is in NetxPanel, AppletPanel and Launcher). The first thread
>>> is what calls applet.init(), applet.start() etc. It creates the second
>>> thread to load the applet (so loading can be interrupted). This second
>>> thread is what calls Launcher.launch() which ends up creating the third
>>> thread to actually load the applet. This third thread is created in a
>>> new ThreadGroup and has the JNLPClassLoader set as the
>>> ContextClassLoader. The patch makes sure that all three threads are
>>> created in the same ThreadGroup and the appropriate context class loader
>>> is set for all of them. This part of the patch is attached to the bug
>>> report. With this patch, all the threads of an applet can load the
>>> classes for the custom look and feel.
>>>
>>> 2. Allows different applets to use different look and feels.
>>>
>>> The patch creates a new AppContext for each applet ThreadGroup. This
>>> means that each applet instance can set its own look and feel and not
>>> affect any other applet (which might lead to visual inconsistency as
>>> well as errors in loading custom look and feels). The AppContext class
>>> (part of sun.awt package) contains a map from ThreadGroup to AppContext
>>> that Swing and AWT can use to make sure they have the AppContext, which
>>> they can then use to index ThreadGroup-specific things like EventQueues
>>> and LookAndFeels. ApplicationInstance stores the AppContext for each
>>> applet instance, so the correct type of AppContext can be returned by
>>> JNLPSecuritymanager when AppContext.getAppContext() calls it to find the
>>> current AppContext.
>>>
>>> I would greatly appreciate it if people can try this patch out. While I
>>> have tested with a large number of jnlp files and many applets, it could
>>> certainly use more testing.
>>>
>>> Any and all feedback is welcome!
>>>
>>> Thanks,
>>> Omair
>>>
>>> [1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=565
>>
>> Anyone? Any comments?
>>
>
> Looks okay to me. The changes look extensive though, and need a bit of
> testing. Ok for commit to HEAD. We'll hold off on backporting this one
> for now.
>

I have pushed a slightly modified version of this patch to HEAD. I am 
perfectly fine with not backporting until it has been tested a little more.

Thanks for the review.

Cheers,
Omair