We Keep Coding

Applet working with Java 8 update 162 and older doesn't work with update 171 and 172

When using Java 8 update 162 and older in Internet Explorer, the applet loads and works as expected. When removing Java 8 update 162 and install Java 8 update 171 or 172, the applet errors with ClassNotFoundException referencing the class listed in the code attribute of the applet tag. I don't see any reason for this in the 171 or 172 release notes or the 171 or 172 bug fixes. I'm using Windows 10 Pro version 1709 build 16299.371. The applet is signed with a certificate that is trusted and still valid. There aren't any exceptions in the Exception Site List and adding an exception for this site (it worked fine without one on Java 8u162) still displays the exception. Using Java 8 update 162 and older is still working on another PC.
When clearing the Application cache in the Java configuration, the applet's JAR file doesn't appear again in the cache.
Are you aware of any changes in Java 8u171 or 172 that affect applets? Do you have any suggestions to resolve this?
Update 1: I'm aware that applets are deprecated in Java 9 and that applets don't work in Firefox and Chrome, but this is in Internet Explorer.
Update 2: I'm also aware that the 3DES Cipher Suites have been disabled in the update to 171 and 172, but the current digest algorithm is SHA-256 and the signature algorithm is SHA256withRSA with a 2048-bit key, which matches the signing certificate's signature algorithm and key. I've even tried signing the applet using Java 8 Update 172 without altering java.security to remove 3DES_EDE_CBC and using that version the ClassNotFoundException still persists as expected.
Update 3: When using Fiddler 4 or Charles as a proxy for Internet Explorer and capturing traffic between the server and the browser, the applet loads and works as expected. Both the Java SE Runtime Environment 8 Update 172 and Java Plug-in 11.172.2 Add-ons are set to Allow on all sites. When I clear the applet from the Resources cache using the Java Cache Viewer in the Java Control Panel, the applet doesn't download in the cache again without the proxy, but if I use a proxy again then it does download into the cache. My guess is that the proxy traffic is being treated as local and so has different permissions. Any other ideas or what permissions it could be?
Update 4: Enabling the debugging options in the Java Control Panel causes the full stack trace to show, where CODE_ATTRIBUTE_VALUE is the value I set on the code attribute of the applet tag. The applet's JAR file doesn't seem to be downloading even though I list it in the archive attribute.
java.lang.ClassNotFoundException: CODE_ATTRIBUTE_VALUE
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
The Java Console now also shows more details about the connection and I see the following which is the cause:
javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(Unknown Source)
at sun.plugin.PluginURLJarFileCallBack.connect(Unknown Source)
at sun.plugin.PluginURLJarFileCallBack.retrieve(Unknown Source)
at sun.net.www.protocol.jar.URLJarFile.retrieve(Unknown Source)
at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source)
at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source)
at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source)
at sun.plugin.net.protocol.jar.CachedJarURLConnection.connect(Unknown Source)
at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFileInternal(Unknown Source)
at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.getJarFile(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.access$900(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.ensureOpen(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.<init>(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath.getLoader(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at sun.security.ssl.InputRecord.read(Unknown Source)
... 40 more
Currently the applet is hosted on Windows Server 2003 using IIS. Moving it to Windows Server 2008 also using IIS causes that problem to go away. Mr. Laitinen was right the TLS connection was using 3DES_EDE_CBC.

JAVA_HOME\lib\security\java.security
Update 171 adds 3DES_EDE_CBC to the list of disabled algorithms (jdk.tls.disabledAlgorithms). Remove it and your applet will work again.

Faced the same issue and it comes down to Update 171 no longer supporting TLS 1.0.
Our webserver was old and only supported TLS 1.0 so the download of the Applet was failing and this could be seen in the Java Console, the connection was being closed.
Upgraded the webserver to support TLS 1.2 and it all works again.

SSLHandshakeException when connecting to Openshift from EclipseIDE... How to solve?

I'm trying to connect to Openshift from Eclipse Mars IDE.
I can very well login to my Openshift account on the web.... Also, going by the error message, I even created new private/public keys and retried connecting but still to no avail. Then I ran a JBossTools update, and tried again, yet no solution.
Here's the closest JBoss Tools BugTrack that I found related to my case, https://issues.jboss.org/browse/JBIDE-14760, but it turns out this is recorded as fixed since JBossTools 4.1.0, whereas I have 4.3.0 on both Mars and Luna
What's even more disturbing is the fact that I've previously been able to make this connection some time ago with Eclipse Luna, then I went back to Luna and tried again but still was unable to make the Openshift connection.
See screenshots of the error messages below;
Eclipse Mars (Error Screenshot below);
Eclipse Luna (Error Screenshot below);
And following is the StackTrace from the logs looks as follows:
!ENTRY org.jboss.tools.openshift.express.ui 4 4 2015-10-09 18:05:58.143
!MESSAGE Could not request https://openshift.redhat.com/broker/rest/api: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No X509TrustManager implementation available
!STACK 0
com.openshift.client.OpenShiftEndpointException: Could not request https://openshift.redhat.com/broker/rest/api: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No X509TrustManager implementation available
at com.openshift.internal.client.RestService.request(RestService.java:120)
at com.openshift.internal.client.RestService.request(RestService.java:92)
at com.openshift.internal.client.AbstractOpenShiftConnectionFactory.getConnection(AbstractOpenShiftConnectionFactory.java:36)
at com.openshift.client.OpenShiftConnectionFactory.getConnection(OpenShiftConnectionFactory.java:198)
at com.openshift.client.OpenShiftConnectionFactory.getConnection(OpenShiftConnectionFactory.java:158)
at com.openshift.client.OpenShiftConnectionFactory.getConnection(OpenShiftConnectionFactory.java:114)
at com.openshift.client.OpenShiftConnectionFactory.getConnection(OpenShiftConnectionFactory.java:103)
at org.jboss.tools.openshift.express.internal.core.connection.Connection.createUser(Connection.java:229)
at org.jboss.tools.openshift.express.internal.core.connection.Connection.connect(Connection.java:205)
at org.jboss.tools.openshift.express.internal.ui.wizard.connection.ConnectionWizardPageModel.connect(ConnectionWizardPageModel.java:247)
at org.jboss.tools.openshift.express.internal.ui.wizard.connection.ConnectionWizardPage$ConnectJob.run(ConnectionWizardPage.java:479)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: com.openshift.internal.client.httpclient.HttpClientException: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No X509TrustManager implementation available
at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.createException(UrlConnectionHttpClient.java:201)
at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.request(UrlConnectionHttpClient.java:161)
at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.request(UrlConnectionHttpClient.java:140)
at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.get(UrlConnectionHttpClient.java:99)
at com.openshift.internal.client.RestService.request(RestService.java:160)
at com.openshift.internal.client.RestService.request(RestService.java:107)
... 11 more
Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No X509TrustManager implementation available
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$10.run(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$10.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.net.www.protocol.http.HttpURLConnection.getChainedException(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at java.net.HttpURLConnection.getResponseCode(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(Unknown Source)
at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.createException(UrlConnectionHttpClient.java:184)
... 16 more
Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No X509TrustManager implementation available
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
at sun.security.ssl.ClientHandshaker.serverCertificate(Unknown Source)
at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source)
at sun.security.ssl.Handshaker.processLoop(Unknown Source)
at sun.security.ssl.Handshaker.process_record(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source)
at com.openshift.internal.client.httpclient.UrlConnectionHttpClient.request(UrlConnectionHttpClient.java:157)
... 15 more
Caused by: java.security.cert.CertificateException: No X509TrustManager implementation available
at sun.security.ssl.DummyX509TrustManager.checkServerTrusted(Unknown Source)
... 29 more
Similar SO posts such as this have offered little or no concrete help either.
Thanks.

please make sure you use latest JDK version since older ones had issues with ssh after heartbleed.
if you see something else please report issue in https://jira.jboss.org/jira/browse/JBIDE

Ok here's what I did and afterwards I was able to establish the Openshift connection from Eclipse Mars
I suspect it was an outdated windows installer problem because all I did was just attempt to re-install my Eclipse Mars which i got from here
NOTE - in my previous installation, I did not notice the update option in the installer so I installed without updating. Well, I believe that copy did not contain the Bug Fixes that solved this particular problem
However, when I attempted to re-install, i noticed the update icon at the top right corner (see image below) so I first of all updated before continuing with the installation process. I guess this just downloaded and applied all the bug fixes before installing.
Afterwards, I tried to establish the OpenShift connection from within my Eclipse Mars IDE without changing anything (...when I say 'anything', I mean my public/private key pair), and Voila, the connection got established.
I hope this helps anyone who runs into this problem and bumps into this post.

How to stop J2SSH SFTP put command from changing permissions

I get the error:
java.io.IOException: This server does not support operations to modify file attributes.
at com.sshtools.j2ssh.sftp.SftpSubsystemClient.getOKRequestStatus(Unknown Source)
at com.sshtools.j2ssh.sftp.SftpSubsystemClient.setAttributes(Unknown Source)
at com.sshtools.j2ssh.sftp.SftpSubsystemClient.changePermissions(Unknown Source)
at com.sshtools.j2ssh.SftpClient.chmod(Unknown Source)
at com.sshtools.j2ssh.SftpClient.put(Unknown Source)
at com.sshtools.j2ssh.SftpClient.put(Unknown Source)
at com.sshtools.j2ssh.SftpClient.put(Unknown Source)
at com.sshtools.j2ssh.SftpClient.put(Unknown Source)
After some digging I found out that the SftpClient.put command does an automatic chmod after it uploads a file. Is there a way for me to disable this?
I know for sure the initial .put works as expected because when I check the remote server for the file, it is present and all bytes accounted for.

NoSuchAlgorithmException when launching JNLP with Java 7

After upgrading to Java 7, when launching remote jnlp, I see the following exception in the Java console:
java.security.KeyStoreException: WIExplorerMy not found
at java.security.KeyStore.getInstance(Unknown Source)
at com.sun.deploy.services.WPlatformService$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.services.WPlatformService.getBrowserClientAuthKeyStore(Unknown Source)
at sun.plugin2.applet.context.InitialJNLPExecutionContext.getBrowserClientAuthKeyStore(Unknown Source)
at sun.plugin2.main.client.DisconnectedExecutionContext.getBrowserClientAuthKeyStore(Unknown Source)
at sun.plugin2.applet.Applet2BrowserService.getBrowserClientAuthKeyStore(Unknown Source)
at com.sun.deploy.security.X509DeployKeyManager.<init>(Unknown Source)
at com.sun.deploy.net.protocol.https.Handler$Initializer$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.net.protocol.https.Handler$Initializer.<clinit>(Unknown Source)
at com.sun.deploy.net.protocol.https.Handler.openConnection(Unknown Source)
at java.net.URL.openConnection(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.createUrlConnection(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doGetRequestEX(Unknown Source)
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.security.NoSuchAlgorithmException: WIExplorerMy KeyStore not available
at sun.security.jca.GetInstance.getInstance(Unknown Source)
at java.security.Security.getImpl(Unknown Source)
... 26 more
In addition the error screen saying "Error. Click for details" appears for about 2 seconds and disappears afterwards.
Other then that, everything seems to function normally.
With Java 6 everything works as expected.
Ideas how to fix it?

I think some of the latest Java 7 updates have obsoleted some encryption schemes, so that would be a completely normal exception to get if you were using one of these while using Java 6.
See this list of enhancements and changes for Java 7:
Weak cipher suites deprecated
Per RFC 4346, RFC 5246, and RFC 5469, some cipher suites have been made obsolete and should not be used. These obsolete suites are all disabled by default in SunJSSE. For details, consult the cipher suite lists in the documentation about the SunJSSE provider.
That being said, that would explain the NoSuchAlgorithmException, but the error message seems to mention something about a missing keystore, so this may be unrelated and we woud need you to provide a SSCCE or anything close enough to one.

I solved this problem by adding
security.provider.11=com.sun.deploy.security.MSCryptoProvider
to C:\Program Files\Java\jre1.8.0_31\lib\security\java.security
Although the error wasn't fatal for me, it is just the javaws trying to read the local browser key store before falling back to the java keystores that are managed by the control panel. Those files are in C:\Users\USERID\AppData\LocalLow\Sun\Java\Deployment\security
Interestingly there is a security provider that comes pre-wired into the java.security file, and it is
security.provider.10=sun.security.mscapi.SunMSCAPI
This provider can also read the browser keystore, but the store type is windows-my, and not WIExplorerMy

Tarlog, do you have any resolution found yet? I have the same problem, I am suspecting that the first problem with KeyStoreException exception only happens if you are trying secure connection. And that sinister "Error. Click for details" issue happens on any Applet loaded through an jnlp.
I could not find any resolution yet.
Edit: For the KeyStoreException I have realised that the problem occured due to apache certificate files were gone somehow. I have generated ceritificate files and restarted apache. The exception no longer occurs.
The other problem with Error window still exists.

With regard to the Error Click for details issue – I resolved this by adding a class to the source that implements javax.jnlp.DownloadServiceListener (can just be a dummy class) and then specifying that class in your jnlp file (applet-desc/#progress-class="YourClass")

Java JRE Mixed Code Security, starting with JRE 1.6.0_19

Java JRE Mixed Code Security, starting with JRE 1.6.0_19 and on
Initially around 2010 a main jar Java Applet was implemented, build, and deploy using JDK/JRE 1.6.0_12; the main jar and third party jars were signed, everything work fine. The main jar java applet and third party jars work fine with JRE 1.6.0_12 thru JRE 1.6.0_18.
However, with the introduction of the Mixed Code security starting with JRE 1.6.0_19, the main jar will not launch with JRE 11.6.0_27 unless the Mixed Code security is disable.We are moving our JRE from 1.6.0_12 to update 27. I am trying to fix this problem, that is, to allow the signed main jar Java applet and the signed third party jars to launch when the Mixed Code security is enable.
I have a main jar that has the Java Applet source code and several third party jars that are use by the main jar; for instance, activation.jar, log4j-1.2.13.jar, ojdbc14.jar, etc.
Using keytool.exe in JDK 1.6.0_27 I created a new keystore that has the private/public key pair for the Java applet. Using jarsigner.exe in JDK 1.6.0_27 I signed the main jar and all the third party jars with the private key successfully; each jar has a signature file .SF and a signature block file .DSA (Digital Signature Algorithm). I exported the public key to be use to verify the signed jars.
The Java Applet and the third party jars are in a web apps' webcontent/applet directory, when the applet is launch using the web app, the main jar and the third party jar are downloaded into the user's computer. The digital signature part works fine, the Java applet is able to launch and work successfully when the JRE Mixed Code security is disable. This still does not solved the Mixed Code security when is enable.
I tried by deploying the main jar as Trusted-Only and Trusted-Library. In both situations when the Mixed Code security is enable, the main jar Java Applets is not able to launch, I get different exceptions but same results.
Trusted-Only :: Mixed Code Enable
.........................
cache: Mark prevalidated: http://hostname:port/path/main.jar true tm=numbers cert=numbers
security: http://hostname:port/path/main.jar is newly asserting Trusted-Only
basic: Plugin2ClassLoader.getPermissions CeilingPolicy allPerms
security: Validate the certificate chain using CertPath API
security: The certificate hasnt been expired, no need to check timestamping info
security: Cannot find jurisdiction list file
security: The CRL support is disabled
security: The OCSP support is disabled
security: This OCSP End Entity validation is disabled
security: Checking if certificate is in Deployment denied certificate store
security: Checking if certificate is in Deployment permanent certificate store
basic: Embedding dialogs not enabled in Configuration
basic: Plugin2ClassLoader.getPermissions CeilingPolicy allPerms
.........................
.........................
network: Cache entry not found [url: http://hostname:port/path/StatLib.jar, version: null]
network: Connecting http://hostname:port/path/StatLib.jar with proxy=DIRECT
network: Connecting http://hostname:port/ with proxy=DIRECT
network: Connecting http://hostname:port/path/StatLib.jar with cookie "CheckboxChecked=Y; JSESSIONID=j_session_id"
network: CleanupThread used 1 us
network: Downloading resource: http://hostname:port/path/StatLib.jar
Content-Length: 62,219
Content-Encoding: null
network: Wrote URL http://hostname:port/path/StatLib.jar to File C:\path\LocalLow\Sun\Java\Deployment\cache\6.0\24\167b0298-1365f142-temp
security: Trusted libraries list file not found
cache: Create from verifier: JarSigningData{hasOnlySignedEntries=true, hasSingleCodeSource=true, hasMissingSignedEntries=false}
cache: Adding MemoryCache entry: http://hostname:port/path/StatLib.jar
basic: Plugin2ClassLoader.isTrustedByPolicy called
basic: Plugin2ClassLoader.isTrustedByPolicy returns false
security: resource name "com/name/statistics/lib/I_Dispatch.class" in http://hostname:port/path/StatLib.jar : java.lang.SecurityException: Trusted-Only loader attempted to load sandboxed resource from http://hostname:port/path/StatLib.jar
04/01/2013 16:58:41,588 - [FATAL Thread-15 com.lfg.name.JavaObjectName.init(JavaName.java:193)] - Error in Method() java.lang.SecurityException: Trusted-Only loader attempted to load sandboxed resource from http://hostname:port/path/StatLib.jar
at com.sun.deploy.security.CPCallbackHandler$ParentCallback.check(Unknown Source)
at com.sun.deploy.security.CPCallbackHandler$ParentCallback.access$1500(Unknown Source)
at com.sun.deploy.security.CPCallbackHandler$ChildElement.checkResource(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.checkResource(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.defineClassHelper(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.access$100(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
.... Java Applet is calling and loading a class in a third party jar that I signed but for some reason is been treated as unsigned ....
.......................
network: Cache entry not found [url: http://hostname:port/path/ojdbc14.jar, version: null]
network: Connecting http://hostname:port/path/ojdbc14.jar with proxy=DIRECT
network: Connecting http://hostname:port/ with proxy=DIRECT
network: Connecting http://hostname:port/path/ojdbc14.jar with cookie "CheckboxChecked=Y; JSESSIONID=j_session_id"
network: CleanupThread used 1 us
network: Downloading resource: http://hostname:port/path/ojdbc14.jar
Content-Length: 1,448,790
Content-Encoding: null
network: Wrote URL http://hostname:port/path/ojdbc14.jar to File C:\path\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\51\534fe7f3-21a4d4ae-temp
security: Trusted libraries list file not found
cache: Create from verifier: JarSigningData{hasOnlySignedEntries=true, hasSingleCodeSource=true, hasMissingSignedEntries=false}
network: CleanupThread used 1 us
cache: Adding MemoryCache entry: http://hostname:port/path/ojdbc14.jar
basic: Plugin2ClassLoader.isTrustedByPolicy called
basic: Plugin2ClassLoader.isTrustedByPolicy returns false
security: resource name "oracle/jdbc/driver/OracleDriver.class" in http://hostname:port/path/ojdbc14.jar : java.lang.SecurityException: Trusted-Only loader attempted to load sandboxed resource from http://hostname:port/path/ojdbc14.jar
java.lang.SecurityException: Trusted-Only loader attempted to load sandboxed resource from http://hostname:port/path/ojdbc14.jar
at com.sun.deploy.security.CPCallbackHandler$ParentCallback.check(Unknown Source)
at com.sun.deploy.security.CPCallbackHandler$ParentCallback.access$1500(Unknown Source)
at com.sun.deploy.security.CPCallbackHandler$ChildElement.checkResource(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.checkResource(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.getResource(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath.getResource(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
..... java applet is loaded a java class in a third party jar that was signed, but is been treated as untrusted.....
Trusted-Library :: Mixed Code Enable
..............................
cache: Mark prevalidated: http://hostname:port/path/main.jar true tm=numbers cert=numbers
basic: Plugin2ClassLoader.getPermissions CeilingPolicy allPerms
security: Validate the certificate chain using CertPath API
security: The certificate hasnt been expired, no need to check timestamping info
security: Cannot find jurisdiction list file
security: The CRL support is disabled
security: The OCSP support is disabled
security: This OCSP End Entity validation is disabled
security: Checking if certificate is in Deployment denied certificate store
security: Checking if certificate is in Deployment permanent certificate store
basic: Embedding dialogs not enabled in Configuration
basic: exception: java.lang.NoClassDefFoundError: org/apache/log4j/Logger.
java.lang.RuntimeException: java.lang.NoClassDefFoundError: org/apache/log4j/Logger
at com.sun.deploy.uitoolkit.impl.awt.AWTAppletAdapter.instantiateApplet(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Logger
at com.path.MainClassApplet.init(MainClassApplet.java:line_number)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at com.sun.deploy.uitoolkit.impl.awt.AWTAppletAdapter$1.run(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$200(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Logger
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 27 more
Ignored exception: java.lang.RuntimeException: java.lang.NoClassDefFoundError: org/apache/log4j/Logger
basic: Dialog type is not candidate for embedding
basic: Removed progress listener: sun.plugin.util.ProgressMonitorAdapter#40ab5b6c
security: Reset deny session certificate store
The main jar applet (Rich Internet Application) is call using JavaScript code in a JavaServer Pages file (HTML page) with the html tag.
It is my understanding that JavaScript code is treated like unsigned code. When a signed applet is accessed from JavaScript code in an HTML page, the signed applet is executed within the security sandbox. This implies that the signed applet essentially behaves like an unsigned applet.
I am debating if I should use JNLP with the Deployment Tookit (deployJava.js) to deploy the applet or if I should add classes to the main JAR file's class-path in the main JAR file's manifest file; whose manifest references a different JAR file (or several different JAR files) that serve as utilities for the purposes of my applet.
Any idea on how to resolved this Mixed Code issue?
Please advise, thanks.

I can confirm the problem is with recent JRE. Calling from JS to Java will give you a "Mixed Code Warning". No matter how you sign or which library you include or not.
So the above comment is not true or not true anymore (after latest JRE upgrade, I'm working with 1.7.0_21).
But luckily it is still permitted to call from java do javascript without problems so the solution we came into for this kind of problem is to implement a commad queue that's being polled from the applet, like the following :
1) wrap each invocation to applet method in an "request object" and put it in a queue, for example:
var jobQueue = [];
function hello(message) {
request = {
cmd:"hello",
arg:"Jack",
callback:function(result) {
alert("I'm saying "+result);
}
}
jobQueue.push(request);
}
2) Create a method to be called from the applet to get a job:
function fetchJob(){
if (jobQueue.length>0) {
return jobQueue.shift();
}
}
3) When the applet starts, spawn a thread or a timer that will call the function fetchJob every X milliseconds. When the function returns a non null request, the applet can execute. The request can carry (like in the above example) even a callback to be called to return a result
That's all. But Beware : if you use a callback to return result beware not to return anything apart from native object or you will end up again with the mixed code warning. Even an array of string won't work. If you need to create a more complex result you need to call back to javascript using liveconnect API and create a native JS Object from Java Applet and then call the callback using that.
Good Luck!