we have an old desktop application which was running on log4j. this application gets deployed using JNLP on the users system and then is connecting to server at our end. we are in the process of upgrading the application to log4j2. we have upgraded the server side code and it works fine. for the JNLP side of code, though we have done all the changes and deployed the application properly we are ending up with an exception which we dont seem to find the cause off. any help here is appreciated..
the exception is as listed below..
java.lang.ClassNotFoundException: org.apache.log4j.Logger
at java.net.URLClassLoader.findClass(Unknown Source)
at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
at java.lang.Class.getConstructor0(Unknown Source)
at java.lang.Class.getConstructor(Unknown Source)
at org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:429)
at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:525)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:272)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:246)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:395)
at com.abcxyz.core.log.Logger.<clinit>(Logger.java:150)
at com.abcxyz.core.log.DefaultLog4jHelper.<init>(DefaultLog4jHelper.java:91)
at com.abcxyz.core.log.DefaultLog4jHelper.initLogger(DefaultLog4jHelper.java:44)
at com.abcxyz.ui.main.CMS.<clinit>(CMS.java:115)
at com.abcxyz.ui.main.InitializeCMS.main(InitializeCMS.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
the exception point to a class file in the log4j-1.2.17.jar (our old jar). i am sure i dont have the old jar anywhere in the code or any part of the code referring the the old jarfile.
pasted below is the sysArgs section of the JNLP where i am referring to the new properties file
I am not familiar with JNLP, but according to your stacktrace, program cannot find. In Log4j2 package org.apache.log4j was changed to org.apache.logging.log4j. As a result it is not available.
One of easiest solutions in your case - to use Log4j 1.x bridge (Here is Migration guide)
If you want to use current version add to <argument> param to use log4j2 impl (by default it is uses org.apache.commons.logging.impl.LogFactoryImpl configured for log4j 1.x)
org.apache.commons.logging.LogFactory=org.apache.logging.log4j.jcl.LogFactoryImpl
we have found the solution. in our case there were two issues
the jar signing was not proper. the jars have manifest files under the meta-inf folder. the value of this folder was corrupted. we manually edited the file and preserved the original values for everything except the SHA keys and then resigned these jar.
in the log4j2-api jar there is a log4j-character.properties file which was getting corrupted while signing the jar using ant script. after the signing we replaced this file in the jar with the copy of the file saved from before the signing.
above to steps resolved our issue. i know what i wrote above might not make much sense to someone. happy to provide screen grabs in case on demand someone comes across this issue.
Related
After updating Java 8u141, my java web start application, run by jnlp stopped working. Do not download the application. And throws these exceptions below. Can someone help me?
com.sun.deploy.net.JARSigningException: Could not verify resource signature: http://www.example.com/myjar.jar
at com.sun.deploy.security.JarVerifier.authenticateJarEntry(Unknown Source)
at com.sun.deploy.security.EnhancedJarVerifier.validate(Unknown Source)
at com.sun.deploy.cache.CacheEntry.processJar(Unknown Source)
at com.sun.deploy.cache.CacheEntry.access$2700(Unknown Source)
at com.sun.deploy.cache.CacheEntry$7.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
at com.sun.deploy.cache.Cache.downloadResourceToTempFile(Unknown Source)
at com.sun.deploy.cache.Cache.downloadResourceToCache(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.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)
Other:
java.lang.SecurityException: digest missing for org/apache/commons/httpclient
at sun.security.util.ManifestEntryVerifier.verify(Unknown Source)
at java.util.jar.JarVerifier.processEntry(Unknown Source)
at java.util.jar.JarVerifier.update(Unknown Source)
at java.util.jar.JarVerifier$VerifierStream.<init>(Unknown Source)
at java.util.jar.JarFile.getInputStream(Unknown Source)
at com.sun.deploy.security.JarVerifier.authenticateJarEntry(Unknown Source)
at com.sun.deploy.security.EnhancedJarVerifier.validate(Unknown Source)
at com.sun.deploy.cache.CacheEntry.processJar(Unknown Source)
at com.sun.deploy.cache.CacheEntry.access$2700(Unknown Source)
at com.sun.deploy.cache.CacheEntry$7.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
at com.sun.deploy.cache.Cache.downloadResourceToTempFile(Unknown Source)
at com.sun.deploy.cache.Cache.downloadResourceToCache(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.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)
I managed to solve this same issue yesterday. This is what worked for me:
Use 7-Zip to open the original, unsigned jar which is throwing the JARSigningException. Probably a good idea to make a copy of the jar first in case anything goes wrong.
Open the META-INF folder and copy MANIFEST.MF somewhere to your PC.
Open the MANIFEST.MF copy in a text editor. Look for a line that says something like "Name: org/apache/commons/httpclient". There could be a few lines like this, depending on the jar. Below this line will probably be other lines like "Implementation-Vendor:...", "Specification-Title:...", etc. In any case, delete all "Name:..." lines and all the subsequent lines in each block.
Save the file, and replace the existing MANIFEST.MF in the jar with the edited version. 7-Zip allows files to be replaced inside jars in-situ.
Re-sign the jar and deploy.
It seems when jars get signed, the "Name:" lines in the manifest can wind up in the middle of the signed classes, which only now seems to be a problem with the release of Java 8u141 but were obviously fine before.
The issue is already fixed in 8u144, please upgrade to 8u144 to avoid this issue http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
I had the same problem with the commons-httpclient-3.1.jar library. Actually I believe it's a bug in the web start, as It worked before and it works with the 8u152 early access. The solution I described here!
The issue is observed in signed JAR files whose manifest contains package version information[1] and does not have a trailing "/" in the name of the package (e.g.: Name: org/apache/xml/resolver). While we work towards resolving this issue, in the interim, users can work-around the issue as follows:
NOTE: We recommend use of this workaround only if the distributor of the JAR files can "re-sign" the JAR files.
Extract the contents of the signed JAR file (e.g.: jar xf jar-file ).
Modify META-INF/MANIFEST.MF file and add a trailing “/” to the name of the package ( e.g.: Name: org/apache/xml/resolver/).
Remove the current signature files ( e.g.: rm -f META-INF/.SF META-INF/.RSA META-INF/*.DSA ).
Recreate the JAR file ( e,g.: jar cfm jar-file META-INF/MANIFEST.MF input-file(s) ).
NOTE: You must use the jar utility. Other jar creation tools might re-introduce the issue.
Re-sign the JAR file.
[1] https://docs.oracle.com/javase/8/docs/technotes/guides/versioning/spec/versioning2.html#wp91706
Source:
http://www.oracle.com/technetwork/java/javase/8u141-relnotes-3720385.html#KnownIssues
This bug is addressed as part of the bug JDK-8184993 and the fix will be available in an out-of-cycle release of JDK 8u144, which is scheduled to be released on later hours of July 26.
I am using an applet in my web application.
I create self-signed applet jar file and compile classes using Oracle JDK 1.7.45.
In client side, I use JRE 1.7.51 and import the certificate.
The applet works fine in three browsers (IE, Mozilla Firefox, Google Chrome) when I use the application on SSL protocol. The problem is that I got the following NullPointerException when I try to run applet in the chrome and Firefox browser while using the application in http without SSL mode, but it still works in IE.
java.lang.NullPointerException
at sun.plugin2.applet.Plugin2ClassLoader.getTrustedCodeSources(Unknown Source)
at com.sun.deploy.security.CPCallbackHandler$ParentCallback.strategy(Unknown Source)
at com.sun.deploy.security.CPCallbackHandler$ParentCallback.openClassPathElement(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.getJarFile(Unknown Source)
at com.sun.deploy.security.DeployURLClassPath$JarLoader.access$1000(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$1.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.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)
In this link http://www.oracle.com/technetwork/java/javase/7u45-relnotes-2016950.html , I see these 2 related 7u45 known issues:
Area: Deployment/Plugin
Synopsis: Applet could fail to load by throwing NPE if pack compression is used with deployment caching disabled.
If a JAR file is using pack compression with manifest entries
Permissions and Caller-Allowable-Codebase while deployment caching is
disabled, then:
• The Permissions manifest entry will be ignored. (This can be seen
from the fact that yellow warning is there on security dialog even
though the Permissions attribute is there.) This only happens if
Caller-Allowable-Codebase attribute is present along with the
Permissions attribute.
• The Caller-Allowable-Codebase attribute will cause the applet to
fail to load by throwing a java.lang.NullPointerException.
If you want to use pack compression with the
Caller-Allowable-Codebase attribute, there are two possible
workarounds:
• Enable caching and all issues listed will disappear.
• Do not use the pack property jnlp.packEnabled=true while deploying
the applets using Caller-Allowable-Codebase andpremissions property.
Instead use the ContentType servlet for serving the pack files.
Area: Deployment/Plugin
Synopsis: Non-JNLP trusted applet fails to load using the file:\ URL. Local trusted applets that do not deploy using a JNLP file will
fail to load by throwing a java.lang.NullPointerException. You can
work around this issue by using one of the following methods:
• Use a JNLP file to launch the applet.
• Try loading the applet over HTTP or HTTPS.
But I don’t use pack compression, also I use a JNLP file to launch the applet and the problem continues to appear.
If your web application is accessed via an authentication step, it is possible that the Java plugins for Chrome and Firefox are unable to download the jar files - when they try to access the URL for the applet, they most probably are greeted by your login page. You could confirm this with Fiddler.
This problem does not appear in IE, because the Java plugin is able to use the session held by the browser itself, so the applet loader is able to immediately download the jar file.
If this is the case for you, the obvious solution is to allow unauthenticated access to the jar file. If you are using IIS, this is done by adding exceptions in web.config.
I've got a Java app that's been in use for awhile and uses embedded Clojure scripts for some of the calculations. Old versions of it still run fine with the current JRE, but if I go to build a new version (only changes to the code are in unrelated Java code) it fails to launch properly. It also runs perfectly fine locally. Only JNLP is affected.
java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessDeclaredMembers")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.Class.checkMemberAccess(Unknown Source)
at java.lang.Class.getDeclaredConstructors(Unknown Source)
at clojure.core$generate_proxy.invoke(core_proxy.clj:137)
at clojure.core$get_proxy_class.doInvoke(core_proxy.clj:261)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:617)
at clojure.core$proxy.doInvoke(core_proxy.clj:335)
at clojure.lang.RestFn.invoke(RestFn.java:1152)
at clojure.lang.Var.invoke(Var.java:465)
at clojure.lang.AFn.applyToHelper(AFn.java:248)
at clojure.lang.Var.applyTo(Var.java:532)
at clojure.lang.Compiler.macroexpand1(Compiler.java:6468)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6546)
at clojure.lang.Compiler.analyze(Compiler.java:6361)
at clojure.lang.Compiler.analyze(Compiler.java:6322)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5708)
at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6009)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6560)
at clojure.lang.Compiler.analyze(Compiler.java:6361)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6548)
at clojure.lang.Compiler.analyze(Compiler.java:6361)
at clojure.lang.Compiler.analyze(Compiler.java:6322)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5708)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5139)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3751)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6558)
at clojure.lang.Compiler.analyze(Compiler.java:6361)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6548)
at clojure.lang.Compiler.analyze(Compiler.java:6361)
at clojure.lang.Compiler.access$100(Compiler.java:37)
at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:529)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6560)
at clojure.lang.Compiler.analyze(Compiler.java:6361)
at clojure.lang.Compiler.analyze(Compiler.java:6322)
at clojure.lang.Compiler.eval(Compiler.java:6623)
at clojure.lang.Compiler.load(Compiler.java:7064)
at clojure.lang.RT.loadResourceScript(RT.java:370)
at clojure.lang.RT.loadResourceScript(RT.java:361)
at clojure.lang.RT.load(RT.java:440)
at clojure.lang.RT.load(RT.java:411)
at clojure.core$load$fn__1451.invoke(core.clj:5530)
at clojure.core$load.doInvoke(core.clj:5529)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$eval1658.invoke(core.clj:6154)
at clojure.lang.Compiler.eval(Compiler.java:6619)
at clojure.lang.Compiler.load(Compiler.java:7064)
at clojure.lang.RT.loadResourceScript(RT.java:370)
at clojure.lang.RT.loadResourceScript(RT.java:361)
at clojure.lang.RT.load(RT.java:440)
at clojure.lang.RT.load(RT.java:411)
at clojure.lang.RT.doInit(RT.java:447)
at clojure.lang.RT.<clinit>(RT.java:329)
at myapp(myapp.java:32)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
The line that it's failing on is this:
RT.loadResourceScript("myapp/clojure_scripts.clj"); // Initialize Clojure script processor with our script
We're currently using a self-signed cert for this app (I've been working with Comodo for the last week trying to get a trusted cert to see if that helps, but I've still not received it and I need this app working ASAP). What's odd to me is that old versions (also self-signed the exact same way) work. I just can't build a new version. I've rolled back my configs so that only actual java code changes should be different, but still no luck. I'm missing something somewhere...
You have to put this into your .jnlp-file:
<security>
<all-permissions/>
</security>
Additionally, depending on your security settings or if using Java 8, add
:manifest {"Permissions" "all-permissions"}
to your project.clj. Clojure requires you to give it the "all-permissions" permission. I'm not entirely sure if it's necessary for all Clojure applications, but I needed to also AOT my project to make it work in a JNLP application. Add this to your ":profiles :uberjar":
:aot :all
:omit-sources true
I created an applet and added it to my JSP page. It was working fine in IE, Chrome when Java Plugin version was 1.5. Recently, I updated Java plugin to 1.6 and now the applet is not loading. The following error is displayed on the console.
load: class GraphApplet.class not found.
java.lang.ClassNotFoundException: GraphApplet.class
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.createApplet(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: open HTTP connection failed:http://cwrug26999:8080/fluids/pages/GraphApplet/class.class
at sun.plugin2.applet.Applet2ClassLoader.getBytes(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.access$000(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
... 9 more
Exception: java.lang.ClassNotFoundException: GraphApplet.class
The GraphApplet.class is located in the same location where JSP page is located.
I used IE with Java 1.5 plugin and the applet is loading fine.
Can anyone point out what I am missing here.
The source code that I am using in the JSP file is below:
<br><center><applet code="GraphApplet.class" codebase="pages/" width="450" height="450">
</applet></center>
Sorry, the applet can not be accessed publicly.
I am using Tomcat5 as the web server and under webapps I have my project folder "fluids" and under this folder I have "pages" folder which contains the JSP files and the applet .class files.
Thanks
The URL http://cwrug26999:8080/fluids/pages/GraphApplet/class.class looks as if the plugin interpreted the code attribute as a class name, not a file name. Try using code=GraphApplet instead.
You could also try using the <embed> tag which isn't deprecated.
I found the issue, after lots of trial and errors it was related to Java Cache. I deleted the Java Cache by going to Control Panel->Java->Temporary Internet Folder->Delete Files...
I also changed the location where the cache files were stored and apparently, the default location was write-protected.
Phew...
Anyway, thanks for the replies
I get the ff. error in Java Console occassionally:
Exception in thread "thread applet-my.package.MyApplet-10" java.lang.NoClassDefFoundError: another/package/SomeClass
at my.package.MyApplet.init(MyApplet.java:95)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ClassNotFoundException: another.package.SomeClass
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
... 3 more
Caused by: java.io.IOException: open HTTP connection failed:https://myserver/mycontext/applets/another/package/SomeClass.class
at sun.plugin2.applet.Applet2ClassLoader.getBytes(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.access$000(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
... 7 more
My applet tag is as follows:
<applet codebase="../../applets" code="my.package.MyApplet" class="invisible" id="myApplet">
<param value="value0" name="param0"/>
...
<param value="valueN" name="paramN" />
<param value="folder/myApplet__0.0.1177.jar,folder/commons-io-1.3.2__0.0.1177.jar,..." name="cache_archive"/>
<param value="0.0.1177.0,0.0.1177.0,...," name="cache_version"/>
</applet>
It is important I stress the word "occasionally". Sometimes the applet is initialized without a hitch. This also means that, often, when the browser is restarted, the problem goes away.
I am aware of applet fails to load class from jar and Applet class loader cannot find a class in the applet's jar but I think they are not applicable to my case. SomeClass and MyApplet are in the same jar and the page is being accessed locally.
Caused by: java.io.IOException: open HTTP connection failed:https://myserver/mycontext/applets/another/package/SomeClass.class
This looks like there is a connection issue with retrieving the jar file from the HTTPS server.
I don't know exactly what version of Java are you running, but you can check the reason of the defect pertaining to your problem here.
If this is not the problem, then make sure that there's enough caching for your JAR file when downloaded else it fails to launch. It's not code issue unfortunately.
UPDATE Is your class SomeClass accessing any remote server or database by any chance?
The exception clearly shows that there is an AccessControl privilege that has been denied.
at sun.plugin2.applet.Applet2ClassLoader.getBytes(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.access$000(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
Bear in mind, that applets are like Flash Objects:
They are both downloaded and run from the client side.
Only difference is that Applets were designed with lots of access control rules such as, it must not connect to servers hidden behind company DMZ (De-Militarized Zone), etc.
If that's the case, I suggest you find a way to retrieve your data outside applets (try servlet?)
UPDATE 2 It seems the JVM can't find the trusted certificate to match with your signed jar.
Since your jar file is signed make sure that the jar file can point your trusted certificate (remember, it must be trusted).
More information, check: http://faq.javaranch.com/java/HowCanAnAppletReadFilesOnTheLocalFileSystem AND http://www.developer.com/article.php/3303561
Probably has something to do with http://download.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html. I.e., one or more of the jars defines/expects a provider. Investigate when there is time.