Develop Reference

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.

Sending over Interface Object from method call hiding implementation super class on server via RMI?

Say I have class SuperNode and an interface Node:
SuperNode implements Node
I have a RMI-Implementation server side and I'm trying to just send the Node over from a method without the user having the source file for SuperNode but they do have the interface Node.
public Node RMIImplServer.getNode();
When I do this I get this error:
java.rmi.UnmarshalException: error unmarshalling return; nested
exception is: java.lang.ClassNotFoundException:
SEHT.somepackage.SuperNode (no security manager: RMI class loader
disabled) at sun.rmi.server.UnicastRef.invoke(Unknown Source) at
java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(Unknown
Source) at
java.rmi.server.RemoteObjectInvocationHandler.invoke(Unknown Source)
at com.sun.proxy.$Proxy0.getDataNodes(Unknown Source) Caused by:
java.lang.ClassNotFoundException: SEHT.somepackage.SuperNode (no
security manager: RMI class loader disabled) at
sun.rmi.server.LoaderHandler.loadClass(Unknown Source) at
sun.rmi.server.LoaderHandler.loadClass(Unknown Source) at
java.rmi.server.RMIClassLoader$2.loadClass(Unknown Source) at
java.rmi.server.RMIClassLoader.loadClass(Unknown Source) at
sun.rmi.server.MarshalInputStream.resolveClass(Unknown Source) at
java.io.ObjectInputStream.readNonProxyDesc(Unknown Source) at
java.io.ObjectInputStream.readClassDesc(Unknown Source) at
java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at
java.io.ObjectInputStream.readObject0(Unknown Source) at
java.io.ObjectInputStream.readObject(Unknown Source) at
java.util.ArrayList.readObject(Unknown Source) 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
java.io.ObjectStreamClass.invokeReadObject(Unknown Source) at
java.io.ObjectInputStream.readSerialData(Unknown Source) at
java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at
java.io.ObjectInputStream.readObject0(Unknown Source) at
java.io.ObjectInputStream.readObject(Unknown Source) at
sun.rmi.server.UnicastRef.unmarshalValue(Unknown Source) ... 5 more
Is what I'm trying to do possible, if so what am I doing wrong, any help would be appreciated.
Finally figured it out...the jar file wasn't including the right files due to a stupid default that I didn't check. Thank you so much EJP for your help.

The client doesn't need any source files. It does however need the object files (.class) files for all types returned by remote methods, available on its CLASSPATH, unless:
... if you don't want to deploy SuperNode.class or whatever it is at the client, you can use the codebase feature. It's complicated.
You will need to install a security manager at the client.
You will need to define the system property java.rmi.server.codebase at the server JVM.
You will need to set it to one or more URLs that are intelligible to the client and that name JAR file(s) containing classes to be loaded dynamically. Typically a codebase item is an HTTP URL. Note that a codebase item referring to the file system local to the server cannot work, as it isn't intelligible to the client.

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

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

java.io.FileNotFoundException log4j

I'm running into a issue, currently I'm getting the below error. Of course this is due to the fact that the user doesn't have access to the C: that's the not the issue. The issue is that I cannot find any references to:
log4j
org.apache.log4j
org.apache.log4j.xml.DOMConfigurator
I've looked in the class paths, imports for all the classes that make up the program, XML Files Associated with the project and I cannot find any references to the items.
I need to know how to track down where this is being referenced so that I can remove it from the project.
Error Example
java.io.FileNotFoundException: c:\javalog\jhook.log (Access is denied)
at java.io.FileOutputStream.openAppend(Native Method)
at java.io.FileOutputStream.<init>(Unknown Source)
at java.io.FileOutputStream.<init>(Unknown Source)
at org.apache.log4j.FileAppender.setFile(FileAppender.java:290)
at org.apache.log4j.RollingFileAppender.setFile(RollingFileAppender.java:194)
at org.apache.log4j.FileAppender.activateOptions(FileAppender.java:164)
at org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:257)
at org.apache.log4j.xml.DOMConfigurator.parseAppender(DOMConfigurator.java:285)
at org.apache.log4j.xml.DOMConfigurator.findAppenderByName(DOMConfigurator.java:171)
at org.apache.log4j.xml.DOMConfigurator.findAppenderByReference(DOMConfigurator.java:184)
at org.apache.log4j.xml.DOMConfigurator.parseChildrenOfLoggerElement(DOMConfigurator.java:502)
at org.apache.log4j.xml.DOMConfigurator.parseRoot(DOMConfigurator.java:471)
at org.apache.log4j.xml.DOMConfigurator.parse(DOMConfigurator.java:921)
at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:790)
at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:682)
at org.apache.log4j.xml.DOMConfigurator.configure(DOMConfigurator.java:811)
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.eglue.jhook.logging.Log4jLogger.internalInvokeStaticMethod(Log4jLogger.java:94)
at com.eglue.jhook.logging.Log4jLogger.<init>(Log4jLogger.java:19)
at com.eglue.jhook.logging.LoggerFactory.getLogger(LoggerFactory.java:22)
at com.eglue.jhook.jni.ValuePair.<clinit>(ValuePair.java:11)
at com.eglue.jhook.jni.DataEnvelope.addValue(DataEnvelope.java:52)
at com.eglue.jhook.jni.HookManager.createMMFServer(HookManager.java:169)
at com.eglue.jhook.jni.HookManager.<init>(HookManager.java:116)
at com.eglue.jhook.Hook.init(Hook.java:43)
at com.eglue.jhook.Hook.guiInitialized(Hook.java:38)
at com.sun.java.accessibility.util.EventQueueMonitor.maybeNotifyAssistiveTechnologies(EventQueueMonitor.java:233)
at com.sun.java.accessibility.util.ComponentEvtDispatchThread.run(EventQueueMonitor.java:649)
Any help/ideas ,

I'd faced this same issue once where a third party library used by me had a copy of log4j internally.
The following code will give the location from where the log4j is loaded
DOMConfigurator.class.getProtectionDomain().getCodeSource().getLocation();
From this you can find out the location of the probable configuration file