Bug 499278 - Yugma viewer doesn't work with openjdk plugin
Yugma viewer doesn't work with openjdk plugin
Product: Fedora
Classification: Fedora
Component: java-1.6.0-openjdk (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Lillian Angel
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2009-05-05 18:44 EDT by Orion Poplawski
Modified: 2009-05-06 15:47 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-05-06 15:47:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Orion Poplawski 2009-05-05 18:44:07 EDT
Description of problem:

Trying to access the yugma viewer (https://www.yugma.com/viewer/viewersignup.php) from Firefox with java-1.6.0-openjdk-plugin- fails to bring up a viewer window.  .xsession-errors contains:

Exception :java.lang.ClassNotFoundException: com/ms/security/PolicyEngine
Exception :java.lang.ClassNotFoundException: com/ms/security/PolicyEngine
Exception in thread "Thread-21" java.lang.NullPointerException
        at javax.swing.ImageIcon.<init>(ImageIcon.java:155)
        at com.yugma.chat.ChatApplet.<init>(Unknown Source)
        at com.yugma.viewer.client.ViewerCommClient.<init>(Unknown Source)
        at Viewer.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:636)

I also tried with the latest rawhide with the same result.
Comment 1 Deepak Bhole 2009-05-05 20:01:47 EDT
This is not  problem with IcedTea. The site/applet is using proprietary Microsoft VM classes (com/ms/security/*) and it needs to migrate from those. 

Please see http://java.sun.com/j2se/1.4.2/docs/guide/deployment/deployment-guide/upgrade-guide/article-05.html for more information.
Comment 2 Orion Poplawski 2009-05-06 12:21:58 EDT
I think the Exception :java.lang.ClassNotFoundException: com/ms/security/PolicyEngine is something of a red herring.  I don't get them and the applet runs with the Sun JRE, but not OpenJDK.
Comment 3 Deepak Bhole 2009-05-06 13:07:10 EDT
Ah, sorry about that then. Didn't know it worked with Sun. Looking into it now..
Comment 4 Deepak Bhole 2009-05-06 13:17:19 EDT
Is there some sort of test session can I join to reproduce this error? I signed up for an account but trying to create a meeting takes me to a download page for the standalone app.
Comment 5 Orion Poplawski 2009-05-06 13:34:50 EDT
I've sent you a session invite by private email.
Comment 6 Deepak Bhole 2009-05-06 15:47:12 EDT
I traced the problem, and it appears to be in the applet side (though not really a bug per se). Sun's site states that one may use this.getClass().getClassLoader() OR Thread.getCurrent().getContextClassLoader() to get the classloader from which resources are loaded[1]. The applet is using the latter.

However, JNLP specifications do not specify (atleast not afaik) how threading should work. Sun's implementation uses the same classloader for starting the applet thread and loading the the applet classes. However, the NetX (IcedTea plugin) uses different threads for the 2. This is cascading into an NPE. The correct fix is for the application to use this.getClass().getClassLoader() .. which makes a bit more sense anyway, as that classloader is where the caller class itself came from.

I have to close this as CANTFIX, as it is unfixable with the current NetX design. If you have a subscription with them and can get them to make the change (even if it is just for testing), I'd be happy to look into the com/ms/* issue. Until the NPE is fixed though, there is no chance of it working.

1: http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/faq.html (question "How can I load resources within my application using Class.forName and ClassLoader.getSystemClassLoader?")

Note You need to log in before you can comment on or make changes to this bug.