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?
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?