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.

Soap UI: ERROR:java.net.SocketException: Connection reset

I am getting ERROR:
java.net.SocketException: Connection reset.
I have followed the below link to resolve the issue. But no luck..
SOAPUI Certificate authentication
http://geekswithblogs.net/gvdmaaden/archive/2011/02/24/how-to-configure-soapui-with-client-certificate-authentication.aspx
I have given the error logs below. Can any one look this and let me know how to resolve this issue?
Thu Mar 23 16:11:51 IST 2017:ERROR:java.net.SocketException: Connection reset
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at sun.security.ssl.InputRecord.readFully(Unknown Source)
at sun.security.ssl.InputRecord.read(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.writeRecord(Unknown Source)
at sun.security.ssl.AppOutputStream.write(Unknown Source)
at org.apache.http.impl.io.AbstractSessionOutputBuffer.flushBuffer(AbstractSessionOutputBuffer.java:131)
at org.apache.http.impl.io.AbstractSessionOutputBuffer.flush(AbstractSessionOutputBuffer.java:138)
at org.apache.http.impl.conn.LoggingSessionOutputBuffer.flush(LoggingSessionOutputBuffer.java:95)
at org.apache.http.impl.AbstractHttpClientConnection.doFlush(AbstractHttpClientConnection.java:270)
at org.apache.http.impl.AbstractHttpClientConnection.flush(AbstractHttpClientConnection.java:275)
at org.apache.http.impl.conn.AbstractClientConnAdapter.flush(AbstractClientConnAdapter.java:197)
at org.apache.http.protocol.HttpRequestExecutor.doSendRequest(HttpRequestExecutor.java:258)
at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport$SoapUIHttpRequestExecutor.doSendRequest(HttpClientSupport.java:113)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:123)
at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:633)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:454)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport$Helper.execute(HttpClientSupport.java:247)
at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport.execute(HttpClientSupport.java:362)
at com.eviware.soapui.impl.wsdl.submit.transports.http.HttpClientRequestTransport.submitRequest(HttpClientRequestTransport.java:324)
at com.eviware.soapui.impl.wsdl.submit.transports.http.HttpClientRequestTransport.sendRequest(HttpClientRequestTransport.java:237)
at com.eviware.soapui.impl.wsdl.WsdlSubmit.run(WsdlSubmit.java:127)
at java.util.concurrent.Executors$RunnableAdapter.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)

WINDOWS
Option 1:
find the following file on your computer (make sure you have write access to the file): C:\Program Files\SmartBear\SoapUI-5.2.1\bin\SoapUI-5.2.1.vmoptions
Add the following line to the file:
-Dsoapui.https.protocols="SSLv3,TLSv1.2"
Run SoapUI with the .exe file (SoapUI-5.2.1.exe)
Option 2: (if option 1 does not work for you).
Edit the following batch file on your computer (make sure you have write access to the file): C:\Program Files\SmartBear\SoapUI-5.2.1\bin\soapui.bat
Add the following line to the file (after: if "%SOAPUI_HOME%" == "" goto START):
set JAVA_OPTS=%JAVA_OPTS% -Dsoapui.https.protocols="SSLv3,TLSv1.2"
Run SoapUI with the batch file (soapui.bat)
MAC (OSX)
The default install location for Mac is in the root Applications folder, and the vmoptions.txt file is in there. Right-click the SOAPUI .app file (in the /Applications folder), and choose "Show Package Contents" to get to the internal files.
/Applications/SoapUI-X.X.X.app/Contents/vmoptions.txt
Add the following line to the vmoptions.txt file:
-Dsoapui.https.protocols=TLSv1.2
LINUX
Edit: bin/SoapUI-5.3.0.vmoptions in SoapUI directory
Add the following line to the file:
-Dsoapui.https.protocols=TLSv1.2
I hope it helps.

Tried all solutions but nothing worked. It started to work after ignoring jre directory in SoapUI. So if above solutions won't work for you then try this:
Close SoapUI
Go to SoapUi directory for example: C:\Program Files\SmartBear\SoapUI-5.3.0\
Rename directory "jre" to "jre.ignore"
Done. Open SoapUi and it should work now.

I think you are using company connection and company firewall is blocking the connection.

In my case, none of the suggestions above were worked, except for this one. (I've added only this line to SoapUI-X.X.X.vmoptions file located in SergiSPN's answer above)
-Djava.net.preferIPv4Stack=true
There must have been some sort of restriction for IPv6 in our company's infrastructure, which I had no idea what it was.

By removing protocols TLS 1.0 in the registry works fine.
Invoke-WebRequest SSL fails?
this post is useful to resolve this issue.

For testing purposes only: If all else fails, you can also just use http instead of https. Just edit the url in the SoapUI window for the request.

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.

Could not initialize class javax.crypto.SunJCE_b

I have a Java servlet application developed and on my develpment PC everything works as expected including using SFTP programmatically to copy over a PDF using HTTPS on port 8443 etc and with SSL certificates in place too.
However, when I attempt to run the application on the Live server I receive the error;
java.lang.NoClassDefFoundError: Could not initialize class javax.crypto.SunJCE_b
On investigation, some are suggesting check the jce.jar. But I have ensured the jce.jar is present and also created a "lib" folder in my project and copied the jar there and placed the jar on my build path but still the problem exists.
How do I resolve this please? Thanks in advance. Here is the console output from right after Tomcat has started the application;
#
08-Jan-2014 10:45:44 org.apache.catalina.startup.Catalina start
INFO: Server startup in 12715 ms
08-Jan-2014 10:47:42 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor run
SEVERE:
java.lang.NoClassDefFoundError: Could not initialize class javax.crypto.SunJCE_b
at javax.crypto.Cipher.getInstance(DashoA13*..)
at com.sun.net.ssl.internal.ssl.JsseJce.getCipher(Unknown Source)
at com.sun.net.ssl.internal.ssl.RSAClientKeyExchange.<init>(Unknown Source)
at com.sun.net.ssl.internal.ssl.ServerHandshaker.processMessage(Unknown Source)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source)
at com.sun.net.ssl.internal.ssl.Handshaker$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.net.ssl.internal.ssl.Handshaker$DelegatedTask.run(Unknown Source)
at org.apache.tomcat.util.net.SecureNioChannel.tasks(SecureNioChannel.java:285)
at org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap
(SecureNioChannel.java:343)
at org.apache.tomcat.util.net.SecureNioChannel.handshake
(SecureNioChannel.java:193)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run
(NioEndpoint.java:1642)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

The jce.jar must be inside the folder WEB-INF/lib of the deployed web application.

I've seen this problem pop up very often and there seems to be a lot of confusion around it. The actual reason this is happening is because the JRE you are using to run your application has been set up with the unrestricted JCE policy jars inside its jre/lib folder (inside your jdk install folder).
If your current project does not need these, then you can move then out of this folder temporarily. This will remove the requirement on the jce libraries and you will no longer see this error.
Hope this helps.

Applet class loader cannot find one of the classes in the jar

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.