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.
Related
Since upgrading to install4j 7.0.5 and Java 10, users that run our application on Windows more and more often report that the application throws
java.lang.NoSuchMethodError: <init>
at javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native Method)
at javafx.graphics/com.sun.glass.ui.Screen.initScreens(Unknown Source)
at javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Unknown Source)
at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
UiLauncher (WAITING)
at java.base#10.0.1/jdk.internal.misc.Unsafe.park(Native Method)
at java.base#10.0.1/java.util.concurrent.locks.LockSupport.park(Unknown Source)
at java.base#10.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown Source)
at java.base#10.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(Unknown Source)
at java.base#10.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(Unknown Source)
at java.base#10.0.1/java.util.concurrent.CountDownLatch.await(Unknown Source)
at platform/javafx.graphics#10.0.1/com.sun.javafx.tk.quantum.QuantumToolkit.startup(Unknown Source)
at platform/javafx.graphics#10.0.1/com.sun.javafx.application.PlatformImpl.startup(Unknown Source)
at platform/javafx.graphics#10.0.1/com.sun.javafx.application.PlatformImpl.startup(Unknown Source)
at platform/javafx.swing#10.0.1/javafx.embed.swing.JFXPanel.initFx(Unknown Source)
at platform/javafx.swing#10.0.1/javafx.embed.swing.JFXPanel.<init>(Unknown Source)
at java.base#10.0.1/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at java.base#10.0.1/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at java.base#10.0.1/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.base#10.0.1/java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.base#10.0.1/java.lang.Class.newInstance(Unknown Source)
at app//...
when starting the application though the install4j created exe file. The error is triggered by creating an instance of javafx.embed.swing.JFXPanel through reflection:
Class.forName("javafx.embed.swing.JFXPanel").newInstance();
We currently suspect that for some reason an incompatible DLL is loaded (glass.dll seems to contain the native method mentioned in the stacktrace).
Does anyone know how to prevent this error? E.g. is there are way to restrict the java.library.path used when executing the application through the install4j-generated exe to the Java runtime environment that was embedded in the installer and installed locally with the application?
According to one user, the error does not occur if the application is started "manually" using the
java -jar app.jar
command. So it seems the problem lies with the install4j created executable.
The workaround to this problem seems to be to remove all occurences of "glass.dll" from your system %PATH%.
I believe a fix must be implemented somewhere else, though; either in the Java runtime or in the Install4j code, but cannot be implemented in the Java code of the actual app:
For some reason the Java runtime version in Install4j checks the bundled JRE last when locating the libraries. In this case the problematic native library is glass.dll which should contain the requested <init> method but if anywhere in your %PATH% there is an older, incompatible version of glass.dll (e.g. from a previous Java 8 installation) that file will be loaded with a higher precedence and then the application will crash natively.
This is not a problem in the code of the application (the java code), nor a problem with the bundled JDK, this is a problem of how the install-4j-generated exe files (or maybe Java internally) tries to resolve native dlls. Instead of checking all path elements first, it should be checking the bundled JRE directory, first.
With Procmon you can see that it loads arbitrarily placed glass.dll files in the path, first: I added one from JDK 1.8 into one of my path elements and got this (plus the crash):
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.
I have a Java 8 project that creates about a dozen JNLP applications. I have built and run them on Windows successfully. The JNLP launches correctly through javaws. I then transfer it as a .tar to a Solaris machine via FTP (in binary mode) and my SA deploys via Tomcat.
When I visit the URL to launch the JNLP over the network, I get an Application Error.
The Exception is:
com.sun.deploy.net.FailedDownloadException: Unable to load resource: https://example.com/webstartdev10g/dev/apps/libs/xerces.jar
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(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
The Wrapped Exception is:
java.util.zip.ZipException: invalid entry size (expected 19075 but got 11917 bytes)
at java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:287)
at java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360)
at java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:238)
at java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377)
at com.sun.deploy.net.HttpDownloadHelper.download(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(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
All of my JNLP apps that depend on xerces have this same error. The apps that don't require xerces seem to be working fine. I checked that the xerces.jar file is the same size on my Windows machine and the Solaris machine. I visited https://example.com/webstartdev10g/dev/apps/libs/xerces.jar directly and was able to download the file and open it. I even replaced my local copy with the downloaded version and ran the app locally without any errors. Based on this, it doesn't seem like there is actually anything wrong with the file.
Any ideas to help me narrow this down?
EDIT:
I turned on the javaws -verbose flag to get more details into what is happening when I launch the JNLP locally with the downloaded jar. As it turns out, I am still getting the error, but it isn't preventing the application from launching. It is just being logged in the console silently, with a different size listed.
java.util.zip.ZipException: invalid entry size (expected 19075 but got 16384 bytes)
I'm still not sure how only this file has this problem or why it reports itself as being the same size on both machines.
I rebuilt, retransfered, and redeployed the apps. They seem to be working now. I am still confused about how the symptoms presented themselves and would be interested in any theories on what happened (other than "the file was somehow corrupted during the transfer").
In any case, using javaws -verbose helped me get some clues about the problem and redeploying the tar file resolved the issue.
I built a small test Java EE Entreprise Application using NetBeans. Everything works fine in NetBeans (version 7.3) when I run/debug it.
I'm now trying to deploy the test app using WebStart. To do so, I have setup a GlassFish server of the same version that is in NetBeans (GF 3.1.2.2) and I have the JDK Version 7 U 51 installed on the machine. For right now, I'm trying to run the WebStart app on the same machine that GlassFish is on so I'm guessing it's using JRE 7U51 also.
However, when I launch the client application from within GlassFish admin page (app deployed fine), I get a NullPointerException.
Here's the full exception trace:
java.lang.NullPointerException
at java.io.StringReader.<init>(Unknown Source)
at org.glassfish.appclient.client.JWSAppClientContainerMain.insertMaskingLoader(JWSAppClientContainerMain.java:186)
at org.glassfish.appclient.client.JWSAppClientContainerMain.main(JWSAppClientContainerMain.java:132)
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)
Here's the JNPL file I get from GlassFish when I want to WebStart the application:
http://pastebin.com/HPddJA3a
Please note that the JNPL file is autogenerated by GlassFish... my EAR doesn't contain one.
This is my first deployment and I've tried many things.... please help! :)
EDIT: More details on how I deploy and access the client app:
I uploaded the EAR file to Glassfish using the admin console (port 4848) and that deployment is successful (no error messages). Then, in the admin console, I see all my EE components (EJB, app jar, etc) and I can launch the client app. This just links to the following URL: http://server-test.com:8080/EEAppTest/EEAppTestEEClient (not a real URL). When I access it, I get the NullPointerException described above.
I have an application acting as a client to a JAX-WS server. The connection works fine if I deploy the application directly by placing the war into the tomcat webapps directory (even if doing a hot deploy). However if I undeploy, then redeploy the application using the tomcat manager (from an automated script) I get the exception below thrown anytime it attempts to establish a connection.
Caused by: java.lang.NullPointerException
at com.ctc.wstx.util.SymbolTable.copyArrays(SymbolTable.java:574)
at com.ctc.wstx.util.SymbolTable.findSymbol(SymbolTable.java:403)
at com.ctc.wstx.sr.StreamScanner.parseLocalName(StreamScanner.java:1770)
at com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2914)
at com.ctc.wstx.sr.BasicStreamReader.handleRootElem(BasicStreamReader.java:2093)
at com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2073)
at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1069)
at com.sun.xml.internal.ws.util.xml.XMLStreamReaderFilter.next(Unknown Source)
at com.sun.xml.internal.ws.streaming.XMLStreamReaderUtil.next(Unknown Source)
at com.sun.xml.internal.ws.streaming.XMLStreamReaderUtil.nextContent(Unknown Source)
at com.sun.xml.internal.ws.streaming.XMLStreamReaderUtil.nextElementContent(Unknown Source)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.hasWSDLDefinitions(Unknown Source)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(Unknown Source)
at com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.parseWSDL(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(Unknown Source)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(Unknown Source)
at com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(Unknown Source)
[... continues into application specific code calling the service ...]
This post showed up here in a search with someone having a similar problem, but had no resolution other than to use spring-ws which isn't really an option for me at the moment.
Has anyone run into this before and been able to resolve the issue? I'm a bit puzzled by what is going on here to make deployment via the tomcat manager different than deploying by placing the files in webapps.
I also encountered this issue. The problem was that I had a dependency on cxf-rt-frontend-jaxws-2.5.2.jar in my classpath, which contains an implementation of org.apache.cxf.jaxws.spi.ProviderImpl that conflicts with the same class in rt.jar that comes with the JDK.
Later versions of cxf-rt-frontend-jaxws no longer contain this class. After upgrading to cxf-rt-frontend-jaxws-2.6.15.jar, the problem was resolved.
I expect that the problem occurs intermittently because the classloader would randomly choose which implementation of ProviderImpl to use each time the WAR is deployed.
In my case, the problem was on SymbolTable class, which was both on com.sun.org.apache.xerces.internal.util.SymbolTable (from rt.jar) and com.ctc.wstx.util.SymbolTable (from wstx-asl-3.2.7.jar). After removing wstx-asl lib from my classpath we made redeployment via tomcat manager with no errors.