Develop Reference

"Unable to load recource" Error running Java Web Start application (JPsychoMorph)

I have no prior experience with Java to be clear.
I'm trying to run this Java app (https://users.aber.ac.uk/bpt/jpsychomorph/), but when launching the application from the .jnlp file in my ..\downloads folder, I get "Unable to launch the application" application error.
In the "Details" part of the error there is:
Error: Unable to load resource:
http://users.abecer.ac.uk.bpt/jpsychomorph/version5/lib/jognl.jnlp
Here is the Exception form the error message:
com.sun.deploy.net.FailedDownloadException: Unable to load resource: http://users.aber.ac.uk/bpt/jpsychomorph/version5/lib/jogl.jnlp
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.getJreResource(Unknown Source)
at com.sun.javaws.LaunchDownload._downloadExtensionsHelper(Unknown Source)
at com.sun.javaws.LaunchDownload.downloadExtensionsHelper(Unknown Source)
at com.sun.javaws.LaunchDownload.downloadExtensions(Unknown Source)
at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source)
at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main.access$000(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
I have tried to add this link to the "Exception site list" in the Java Control panel,
but it didn't make difference. I even added multiple versions of this link (http and https versions).
My system:
Windows 10 pro, 21H2 AMD Ryzen 5 5500U
Java 64bit, Version 8 update 341 (build 1.8.0_341-b10) I have Java security settings "High"
Browser: Firefox Deveoper edition (but same resoults on Chrome)
(In my Firefox file format setting list I don't see .jnlp files... somewhere I read, that you should set there .jnlp files to be opened with Firefox, but I don't see that file type there.. it that a problem maybe?)
At this point I don't know what to try.
Thanks for any advice!

Java Web Start not working after updating Java 8u141 - java.lang.SecurityException: digest missing for org/apache/commons/httpclient

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.

Java web start error after update Java 7u17 to Java 8u25 SecurityException

Java web start error after update Java 7u17 to Java 8u25
SecurityException com.sun.deploy.net.JARSigningExceptions: Found unsigned entry in resource:
My application deploy via JWS using self sign method.
I use JDK6 to generate keystore, cert and sign the jar. And use JRE7u17 (actually start from JRE6u21 then update it along the way) on client side to load jnlp file and start the application.
Everything works fine until I update client JRE to the newest one which is 8u25. Then I double click shortcut as always to start the application. However the below error occur.
All environments are on Windows
com.sun.deploy.net.JARSigningException: Found unsigned entry in resource:(http://xxx.xxx.xxx.xxx/app/app.jar, 0.2.2.01)
at com.sun.javaws.security.SigningInfo.getCommonCodeSignersForJar(Unknown Source)
at com.sun.javaws.security.SigningInfo.check(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResourcesHelper(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResources(Unknown Source)
at com.sun.javaws.Launcher.prepareResources(Unknown Source)
at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main.access$000(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
The error said about unsigned entry, but I didn't modify the application jar at all. Therefore, I think that it was properly signed.
I tried to search around the internet and didn't find specific solutions, so I would like your help to resolve this problem.

Why's Clojure failing from JNLP now?

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

JMS Exception what type of exception is this?

I am getting the following error when running my code in production. But the same doesnt happen in the qa environment or the dev environment. I am thinking that this might be a problem in the jndi name. But i am not 100 percent sure. Can anyone tell me what will cause this exception?
org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 203 completed: No
at com.sun.corba.se.impl.logging.ORBUtilSystemException.writeErrorSend(Unknown Source)
at com.sun.corba.se.impl.logging.ORBUtilSystemException.writeErrorSend(Unknown Source)
at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.writeLock(Unknown Source)
at com.sun.corba.se.impl.encoding.BufferManagerWriteStream.sendFragment(Unknown Source)
at com.sun.corba.se.impl.encoding.BufferManagerWriteStream.sendMessage(Unknown Source)
at com.sun.corba.se.impl.encoding.CDROutputObject.finishSendingMessage(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.finishSendingRequest(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete1(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.invoke(Unknown Source)
at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.is_a(Unknown Source)
at org.omg.CORBA.portable.ObjectImpl._is_a(Unknown Source)
at weblogic.corba.j2ee.naming.Utils.narrowContext(Utils.java:126)
at weblogic.corba.j2ee.naming.InitialContextFactoryImpl.getInitialContext(InitialContextFactoryImpl.java:94)
at weblogic.corba.j2ee.naming.InitialContextFactoryImpl.getInitialContext(InitialContextFactoryImpl.java:31)
at weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFactory.java:41)
at javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
at javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
at javax.naming.InitialContext.init(Unknown Source)
at javax.naming.InitialContext.<init>(Unknown Source)

This looks like the symptoms of this Java bug - http://bugs.sun.com/view_bug.do?bug_id=6553303
If this is the problem, then the fix is to upgrade the JVM on your production boxes to a more recent version. The bug report's closure details tell you the minimum patch level (for Java 5 & Java 6) you need fo the fix.