Why's Clojure failing from JNLP now? - java

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

Related

log4j2 in JNLP results Classnotfoundexception

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.

Java.util.PropertyPermission Failure

I'm trying to run a simple Java Web Start App. I wrote my code in NetBeans and used the jar exported for my .jnlp file. Eventually I plan on having the code read from the windows registry and use that data, but for now all I'm doing is creating a String then calling System.out.println(strName); I am self signing the jar using the strategy outlined here. When I download and run the .jnlp, I get the following exception:
java.security.AccessControlException: access denied ("java.util.PropertyPermission" "jna.debug_load" "read")
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at com.sun.javaws.security.JavaWebStartSecurity.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
at java.lang.System.getProperty(Unknown Source)
at java.lang.Boolean.getBoolean(Unknown Source)
at com.sun.jna.Native.<clinit>(Native.java:95)
at com.sun.jna.Pointer.<clinit>(Pointer.java:41)
at com.sun.jna.platform.win32.WinReg$HKEY.<init>(WinReg.java:32)
at com.sun.jna.platform.win32.WinReg.<clinit>(WinReg.java:61)
at cvbxtractor.CvbXtractor.main(CvbXtractor.java:17)
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)
I have tried adding permission java.util.PropertyPermission "jna.debug_load", "read"; to my java.policy file, I have tried signing and resigning any jars it might be using, and made sure my .jnlp has the
<security>
<all-permissions/>
</security>
line in it, but none have helped. I'm sure I'm just missing some security toggle somewhere, if this is easy please forgive me, this is my first Java Web Start App.
As of java 7u45, you can't read system properties when running from a jnlp. Oracle basically ruined javaws. If you're writing a new app, I would recommend staying away from java webstart. It's broken and they just keep making it worse by forcing security updates that break your application.
That being said, one partial workaround to this problem is to prefix all of your properties with jnlp.. So, you'd have to rename your property jnlp.jna.debug_load. If it's a property from a third party library/jar you're using, you're out of luck.

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.

Self-signed (jdk 7u45) Applet got NullPointerException when runs on SSL in firefox and chrome

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.

RDF-Gravity 1.0 - unable to launch the application

I was trying to install RDF-Gravity 1.0 on Windows 7 x64bit machine. The installation failed with a message Unable to launch the application. The exception in the Details/Exceptionis provided below. I will be thankful to you, if any body knows how to get over it.
java.lang.SecurityException: com.sun.deploy.net.JARSigningException: Found unsigned entry in resource: http://semweb.salzburgresearch.at/apps/rdf-gravity/jws/colt.jar
at com.sun.deploy.cache.CacheEntry.checkAllJarEntriesSigned(Unknown Source)
at com.sun.deploy.cache.CacheEntry.getJarFile(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)
Caused by: com.sun.deploy.net.JARSigningException: Found unsigned entry in resource: http://semweb.salzburgresearch.at/apps/rdf-gravity/jws/colt.jar
... 15 more
Edited: I have followed the useful comments by Joshua and they look promising. Since I do not have much knowledge about JNLP, I could not figure out "How to make the Java Web Start application working with disabled cache?". Alternatively, having gone through a blog for rdf visualization tools, I have found something similar to RDF-Gravity called welkin, which also visualizes RDF.
The reason why the Webstart version of RDF Gravity does no longer work on some systems is that the certificate for the colt.jar is no longer accepted by some JVM versions. For those who are interested in details this thread explains why this is the case.
People who are affected by that can download the RDF Gravity version available here. The "rdf-gravity.jar" contained in the zip archive is a runable jar.
best
Rupert

Categories

Resources