Problems with the 1.5.0 Java Plug-in on Mac OS X


D

d_cymbal

Sorry for the crosspost, I wasn't sure if this was best targeted at
Java or at OS X.

I am having some big problems with the 1.5.0 Java Plug-in on Mac OS X
10.4.7.

I have a Java applet that is working fine on Windows with IE5.0 and
FireFox1.5 and on Linux with FireFox1.5 with the 1.5 Java Plug-in. I am
having problems running it on OS X with both the Safari and FireFox
browsers.

The initial problem is the download and execution of the applet. I've
tried using both the <object> and <applet> tags but see the same
problem with each. What happens when the applet tries to load is the
following exception gets tossed into the Java console:

Java Plug-in 1.5.0
Using JRE version 1.5.0_06 Java HotSpot(TM) Client VM

load: class com.company.product.component.LogViewer not found.
java.lang.ClassNotFoundException:
com.company.product.component.LogViewer
at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:168)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:119)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at sun.applet.AppletClassLoader.loadCode(AppletClassLoader.java:599)
at sun.applet.AppletPanel.createApplet(AppletPanel.java:721)
at sun.plugin.AppletViewer.createApplet(AppletViewer.java:1807)
at sun.applet.AppletPanel.runLoader(AppletPanel.java:650)
at sun.applet.AppletPanel.run(AppletPanel.java:324)
at java.lang.Thread.run(Thread.java:613)
Caused by: java.io.IOException: open HTTP connection failed.
at sun.applet.AppletClassLoader.getBytes(AppletClassLoader.java:271)
at sun.applet.AppletClassLoader.access$100(AppletClassLoader.java:44)
at sun.applet.AppletClassLoader$1.run(AppletClassLoader.java:158)
at java.security.AccessController.doPrivileged(Native Method)
at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:155)
... 9 more

The HTML snippets I had tried were either:

<object
classid="java:com.company.product.component.LogViewer"
type="application/x-java-applet"
archive="logviewer.jar">
</object>

or:

<applet
archive="logviewer.jar"
code="com.company.product.component.LogViewer.class">
</applet>

I thoughts the class not found was strange, so I looked at the logs on
the
webserver, and what I saw was:

GET: /com/company/product/component/LogViewer.class
GET: /com/company/product/component/LogViewer.class

(when using <object>)

and

GET: /com/company/product/component/LogViewer.class
GET: /com/company/product/component/LogViewer/class.class

(when using <applet>)

Every other system I tested would simply request:

GET: /logviewer.jar

It looks to me like the OS X plug-in is trying to download the main
class file to execute vs. downloading the containing jar.

Here is the kicker: If I clear the classloader cache from the Java
Console (option 'x') and refresh the page, the OS X system now requests

GET: /logviewer.jar

Like every other system and runs my applet just fine.

However, the next problem I run into is that on subsequent attempts to
run the applet, it looks like the Plug-in tries to run the applet out
of its cache. The applet launches OK, the applet OK, but then every
time the applet attempts to make an HTTPS connection back to the server
it fails with the following exception:

(Note the cert on the server is self-signed. Normally you are
presented with the security dialog and are allowed to click through
this and allow the applet to run).

java.security.AccessControlException: access denied
(java.util.PropertyPermission jnlpx.home read)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
at
java.security.AccessController.checkPermission(AccessController.java:427)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at
java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285)
at java.lang.System.getProperty(System.java:627)
at
com.sun.deploy.security.MacOSXTrustDeciderDialog.showDialog(MacOSXTrustDeciderDialog.java:111)
at
com.sun.deploy.security.X509DeployTrustManager.checkServerTrusted(X509DeployTrustManager.java:390)
at
com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted(SSLContextImpl.java:320)
at
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:840)
<some ssl functions deleted....>
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
javax.net.ssl.SSLHandshakeException:
java.security.cert.CertificateException: Java couldn't trust Server
at
com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150)
at
com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1476)
at
com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:174)
<some ssl functions deleted....>
at
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:402)
at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:170)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:913)
at
java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:367)
at
sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:318)
at
com.company.product.component.LogViewer.requestBuffer(LogViewer.java:345)
at
com.company.product.component.LogViewer$UpdateTask.run(LogViewer.java:426)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Caused by: java.security.cert.CertificateException: Java couldn't trust
Server
at
com.sun.deploy.security.X509DeployTrustManager.checkServerTrusted(X509DeployTrustManager.java:439)
at
com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted(SSLContextImpl.java:320)
at
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:840)
... 15 more

The only way I have been able to resolve this problem is to completely
shutdown Safari, then from the Java Preferences application clear the
cache completely, relaunch Safari, get the initial problem #1 mentioned
above and use the Java Console clear classloader cache trick to get the
applet to run.

Again, I do not see this behavior on the Windows and Linux systems we
have tested.

Does anybody have any ideas on this? Is the behavior of Java Plug-in
for OSX modified for behavior and not just a straight port to OS X?
 
Ad

Advertisements


Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top