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-1.6.0.0-15.b14.fc10.i386 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.
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.
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.
Ah, sorry about that then. Didn't know it worked with Sun. Looking into it now..
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.
I've sent you a session invite by private email.
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?")