[RFC][plugin]: Class loading problem.

[Omair Majid]

On 04/29/2011 01:53 PM, Denis Lila wrote:
>>> @@ -39,14 +40,51 @@
>>>     *
>>>     * @author Francis Kung<fkung at redhat.com>
>>>     */
>>> + at SuppressWarnings("serial")
>>>    public class NetxPanel extends AppletViewerPanel {
>>
>> Is there a particular reason you are suppressing this warning?
>>
>
> It's a pet peeve of mine ;)
> Warning marks in eclipse bother me more than they reasonably
> should. Should I change it back?
>

If it's a warning and it bothers you, I think we should fix the cause 
(thought that should be a separate patch), not merely suppress the warning.

>>> - // create the frame.
>>> - PluginAppletViewer.framePanel(identifier, handle, panel);
>>> + // Framing the panel needs to happen in a thread whose thread
>>> group
>>> + // is the same as the threadgroup of the applet thread. If this
>>> + // isn't the case, the awt eventqueue thread's context classloader
>>> + // won't be set to a JNLPClassLoader, and when an applet class
>>> needs
>>> + // to be loaded from the awt eventqueue, it won't be found.
>>> + Thread panelInit = new Thread(panel.getFutureTG(), new Runnable()
>>> {
>>> + @Override public void run() {
>>> + panel.createNewAppContext();
>>> + // create the frame.
>>> + PluginAppletViewer.framePanel(identifier, handle, panel);
>>> + panel.init();
>>> + // Start the applet
>>> + initEventQueue(panel);
>>> + }
>>> + }, "NetXPanel initializer");
>>>
>>> - panel.init();
>>> -
>>> - // Start the applet
>>> - initEventQueue(panel);
>>> + panelInit.start();
>>> + while(panelInit.isAlive()) {
>>> + try {
>>> + panelInit.join();
>>> + } catch (InterruptedException e) {
>>> + }
>>> + }
>>>
>>
>> This part looks fine to me, but I am not too familiar with the
>> concurrency requirements and communication between threads that goes
>> on in PluginAppletViewer.
>
> This code is meant to be as close to the original as possible, with the
> exception that it should happen in the same TG as the one of the thread
> that will do the loading in panel.init() (and with a new AppContext so
> that we get new eventqueue threads for new applets).
>
> What do you think about the TODO?
> I think you suggested something like that to me yesterday. That's why
> I put the TODO in there. However, what we have now is what we've always
> had (as far as the TG name goes), and I wasn't sure I should change it.
>

No, I think it's fine for now. AFAIK, knowing the name of the thread 
group is not sufficient to create other threads in it. As long as other 
applets cant access/use these other threadgroups, we are fine.

Cheers,
Omair