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.
Related
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.
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 have been using Jenkins for quite some time for Continuous integration with my Java projects.
Recently I tried the Jenkins Deploy Plugin (https://wiki.jenkins-ci.org/display/JENKINS/Deploy+Plugin) to deploy my war file on tomcat 7. However, I am unable to do so as I am getting the following error:
Deploying C:\Program Files (x86)\Jenkins\jobs\MY_PROJS\workspace\target\projs.war to container Tomcat 7.x Remote
[C:\Program Files (x86)\Jenkins\jobs\MY_PROJS\workspace\target\projs.war] is not deployed. Doing a fresh deployment.
Deploying [C:\Program Files (x86)\Jenkins\jobs\MY_PROJS\workspace\target\projs.war]
ERROR: Publisher hudson.plugins.deploy.DeployPublisher aborted due to exception
org.codehaus.cargo.container.ContainerException: Failed to deploy [C:\Program Files (x86)\Jenkins\jobs\MY_PROJS\workspace\target\projs.war]
at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.deploy(AbstractTomcatManagerDeployer.java:115)
at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.redeploy(AbstractTomcatManagerDeployer.java:187)
at hudson.plugins.deploy.CargoContainerAdapter.deploy(CargoContainerAdapter.java:64)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:90)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:77)
at hudson.FilePath.act(FilePath.java:914)
at hudson.FilePath.act(FilePath.java:887)
at hudson.plugins.deploy.CargoContainerAdapter.redeploy(CargoContainerAdapter.java:77)
at hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:47)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:776)
at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.post2(MavenModuleSetBuild.java:1030)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:725)
at hudson.model.Run.execute(Run.java:1695)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:519)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:231)
Caused by: java.io.IOException: Error writing request body to server
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.checkError(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.write(Unknown Source)
at java.io.BufferedOutputStream.flushBuffer(Unknown Source)
at java.io.BufferedOutputStream.write(Unknown Source)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.pipe(TomcatManager.java:583)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.invoke(TomcatManager.java:501)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.deployImpl(TomcatManager.java:547)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.deploy(TomcatManager.java:273)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.deploy(TomcatManager.java:256)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.deploy(TomcatManager.java:240)
at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.deploy(AbstractTomcatManagerDeployer.java:107)
... 17 more
java.io.IOException: Error writing request body to server
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.checkError(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.write(Unknown Source)
at java.io.BufferedOutputStream.flushBuffer(Unknown Source)
at java.io.BufferedOutputStream.write(Unknown Source)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.pipe(TomcatManager.java:583)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.invoke(TomcatManager.java:501)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.deployImpl(TomcatManager.java:547)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.deploy(TomcatManager.java:273)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.deploy(TomcatManager.java:256)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.deploy(TomcatManager.java:240)
at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.deploy(AbstractTomcatManagerDeployer.java:107)
at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.redeploy(AbstractTomcatManagerDeployer.java:187)
at hudson.plugins.deploy.CargoContainerAdapter.deploy(CargoContainerAdapter.java:64)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:90)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:77)
at hudson.FilePath.act(FilePath.java:914)
at hudson.FilePath.act(FilePath.java:887)
at hudson.plugins.deploy.CargoContainerAdapter.redeploy(CargoContainerAdapter.java:77)
at hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:47)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:776)
at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.post2(MavenModuleSetBuild.java:1030)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:725)
at hudson.model.Run.execute(Run.java:1695)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:519)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:231)
Thanks in advance for your help.
In most cases, errors like this are simply caused by URL parameter being incorrect.
See similar issue documented/resolved here where URL parameter was the culprit. Additionally, I highly reccomend thoroughly covering Apache Manager Documentation.
However, as mentioned in above comment, this may also be caused by version mismatch between the application itself and what is actually being deployed.
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 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.