I think this is a 2 part question.
My versions:
I developed using Java jdk1.8.0_144,
Server JVM jdk1.8.0_77,
Server Tomcat apache-tomcat-8.5.23
Error:
16-Apr-2018 11:57:31.041 SEVERE [http-nio-13571-exec-1] org.apache.catalina.core.AprLifecycleListener.init An incompatible version [1.1.32] of the APR based Apache Tomcat Native library is installed, while Tomcat requires version [1.2.14]
I tried different Java version, including Java 9 and Java 7. On these version my app does not even start up. I tried 2 different Java 8 versions supplied by the hosting company and still get the same error.
Any ideas please?
Then I got the error above and did nothing else on the website. Did not even browse it. Hours later I get this error:
java.lang.OutOfMemoryError: Metaspace
The hosting company says I musttake a better hosting option for more Memory and then the errors will go away?
What do you think?
I think problem is conflicting your tomcat version, it may be older version.
Download the native library of required version and replace this file tcnative-1.dll(locate at your tomcat bin folder) with new downloaded file.
Download from this link https://archive.apache.org/dist/tomcat/tomcat-connectors/native/.
It will work.
Related
I compiled a Servlet with java 15 and tried to run it with Tomcat 10 but got the error:
"java.lang.UnsupportedClassVersionError: Servlet1 has been compiled by a more recent version of the Java Runtime"
Looking at the Tomcat Properties I noticed Tomcat uses Java 8 that is installed also on my PC.
So I went to the Tomcat Properties under the Java tab and put down jdk-15.0.1\bin\jvm.dll
-> Tomcat didn't start anymore.
I noticed that in the same properties under the Java tab, there is "Java Classpath" but it's value was
Tomcat-Dir\bin\bootstrap.jar (I think). Then I changed this to jdk-15.0.1\bin (and variations thereof).
Now to my problem - Tomcat doesn't start anymore "ClassNotFoundException ... Bootstrap" I can change back the path to the JVM by checking "Use default", but I don't remember exactly the path under "Java Classpath". Can someone tell me what the default value needs to be here for Tomcat10. I would like to at least be able to start Tomcat again.
I'm talking about this Tab in the Tomcat properties
The problem you are describing (immediate service start failure, nothing in Tomcat's logs and a short line in commons-daemon.log) happens when there is a mismatch between the architecture of the Procrun service application (installed as bin\tomcat10.exe in your Tomcat installation) and the architecture of the jvm.dll: a 32-bit executable cannot load a 64-bit library and viceversa.
You can confirm it with tomcat10.exe version (works only in an administrator cmd)) and java -version.
To solve this you need to download the complete Apache Commons Daemon distribution for Windows (cf. download area) and replace tomcat10.exe with the appropriate prunsrv.exe executable (there are two versions in the zip archive).
Regarding which libraries should be in Tomcat's classpath, you just need bin\bootstrap.jar and bin\tomcat-juli.jar in your server's installation folder.
Remark: The Windows MSI installer for Tomcat contains both prunsrv.exe versions, but installs only one depending on the architecture of the Java executable you choose during installation. Probably you have a 32-bit Java 8 and 64-bit Java 15. For a long time the java.com page automatically proposed the 32-bit version of Java.
I want deploy java webapp on vps server with ubuntu. I installed jdk, jre and tomcat, but when i try to see tomcat standard welcome page it returns error: org.apache.jasper.JasperException: Unable to compile class for JSP. Here is the link to my server: http://something.nazwa.pl:8080.
How can i repair this error and how properly prepare vps to java application?
I had never been using Linux,so it is difficult to me.
Ok. Try to set the JDK 8 of oracle or OpenJDK 8. Becasue from the Site of Apache Tomcat
Building Apache Tomcat requires a JDK (version 8) to be installed. You
can download one from
And you jave OpenJDK 9
And remember
IMPORTANT: Set an environment variable JAVA_HOME to the pathname of
the directory into which you installed the JDK release.
--- Edit ---
Ok going more deeper I found that tomcat 9 can run in Open JDK 9, but it might contains bugs
For example, users were successfully running Tomcat 8 on Java 8 many
months before the first stable Java 8 release. However, users of early
access builds should be aware of the following:
It is not unusual for the initial early access builds to contain bugs
that can cause problems for web applications running on Tomcat. If the
new Java version introduces new language features then the default JSP
compiler may not support them immediately. Switching the JSP compiler
to javac may enable these new language features to be used in JSPs. If
you do discover an problem using a Java early access build, please ask
for help. The Tomcat user's mailing list is probably the best place to
start.
From Apache Tomcat.
Conclusion
Try to go with JDK 8 of oracle and set your enviorement variable
Getting below error while deploying application in liberty server.
It seems drools compatibility issues with java 1.8.I cannot change my drools / mvel jar version since it requires significant change in drools. In one of the forum , i have read to use updated ecj version jar So I have updated ecj jar to 4.5.1 version but even though getting the error .This solution works in tomcat and WAS Server without any issues with java 1.8 migration
Caused by: java.lang.VerifyError: (class: ASMAccessorImpl_7258891721511957152780, method: getKnownEgressType signature: ()Ljava/lang/Class;) Illegal type in constant pool.
Can anyone please let us know what need to do for solving the above error
Normally I've seen this problem occur when using .class files compiled with one JDK and running with another (e.g. compiled w/ IBM JDK 7 and running with Oracle JDK 8).
To work around the VerifyError you can add -noverify to your JVM_ARGS (via jvm.options).
For more detailed analysis it would be helpful to know:
the complete stack trace of the error
what JDK you are running with
the version of WAS Liberty you are using
I'm trying to put SAP JCO3 libraries to my work server that has an OS "Win 2003 Server". The SAP JCO3 libraries worked fine on my localhost which has an OS "Windows 7". However when I performed the same procedure for installation on my work server and tried to use the libraries, I've been getting this error,
> java.lang.ExceptionInInitializerError: Error getting the version of
> the native layer:
> java.lang.UnsatisfiedLinkError:***********\sapjco3.dll: This
> application has failed to start because the application configuration
> is incorrect. Reinstalling the application may fix this problem
Can anyone help me with this issue. Thanks in advance.
The issue is because of Visual 2005 C++ runtime redistributable. The version require by sapjco3.dll should be minimum of 8.0.50727.4053 to work, but however the version on my work server is much lower than this one and lead to this issue. Then I asked my system admin to update it. And now it works.
The sapjco jar depends on the sapjco3.dll native library.
Your local workstation must have that .dll somewhere where java can get at it.
I'd see where the dll is located on your local workstation, and figure out how it's being referenced, then see if you can replicate that on the server.
There are different versions of the .dll for 32-bit and 64-bit windows, so it's possible that you may need a different version on the server than you need on your local workstation.
I am trying to run a java jnlp application from my computer. Every time I try launch the file I get the error java.lang.NoClassDefFoundError: java/security/CodeSigner
From searching Google it seems to be a common enough problem and is normally blamed on 'java 6'. I couldn't find a solution that doesn't involve rolling back to an older java version.
Does anyone know how fix this without reverting versions?
Looks like SUN JRE 1.6.0_14 was the last SUN JVM without that nasty bug... I'd install that version in parallel and use it more or less exclusively for jnlp applications, that still request Java 1.4. (guess you can't change the jnlp application so that it request a higher Java version)