0

I have a web application that I copied from one server to other. I have copied the WAR file in webapps folder and it was uncompressed correctly.

But when application is started, this error is logged:

IINFO: Deploying web application archive /var/lib/tomcat7/webapps/admin.war
Apr 03, 2019 10:36:50 PM org.apache.catalina.loader.WebappClassLoader validateJarFile
INFO: validateJarFile(/var/lib/tomcat7/webapps/admin/WEB-INF/lib/tomcat-embed-core-8.5.11.jar) - jar not loaded. See Servlet Spec 3.0, section 10.7.2. Offending class: javax/$
Apr 03, 2019 10:36:50 PM org.apache.catalina.loader.WebappClassLoader validateJarFile
INFO: validateJarFile(/var/lib/tomcat7/webapps/admin/WEB-INF/lib/tomcat-embed-el-8.5.11.jar) - jar not loaded. See Servlet Spec 3.0, section 10.7.2. Offending class: javax/el$

What does it mean? it may be due to jvm version in the other server?

This is the Java version in source server:

java version "1.8.0_92"
Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.92-b14, mixed mode)

And this is in target server:

java version "1.7.0_181"
OpenJDK Runtime Environment (IcedTea 2.6.14) (7u181-2.6.14-0ubuntu0.3)
OpenJDK 64-Bit Server VM (build 24.181-b01, mixed mode)

Regards Jaime

jstuardo
  • 3,901
  • 14
  • 61
  • 136
  • It looks like your war has an embeded tomcat core libraries in it which are for tomcat 8.5.11 version... And you are running it on tomcat7. Maybe try to migrate to tomcat 8.5? – MGorgon Apr 05 '19 at 23:53

1 Answers1

0

I'm not pretty sure if it is duplication this or not. Anyway that similar issue contains a helpful answer of BalusC I would like to share (link).

BalusC's answer:

This is a sign of classpath pollution. The JSP/Servlet API libraries are appserver implementation dependent and belongs in case of Tomcat 6 in the Tomcat/lib folder and should in no way be moved nor duplicated somewhere else. It's recipe for portability trouble and collisions in classloading as you've encountered now. The libraries in webapp have precedence in classloading. If the servlet-api.jar is encountered there, it is in turn looking for its dependencies there, but they were apparently missing in there.

You must remove any appserver-specific libraries from the webapp's Webapp/WEB-INF/lib. You should only put webapp-specific libraries in there. Keep appserver-specific libraries in the appserver's own default classpath, which is the Tomcat/lib in your case. Keep it untouched. You can at most add libraries which you'd like to share among all webapps in there, or even better, configure the shared.loader in Tomcat/conf/catalina.properties for that.

Also remove any appserver-specific and webapp-specific libraries from the JDK/lib and JRE/lib folders, if any. I've seen too often that some starters move/copy the libraries there because "it otherwise doesn't compile". You should never copy non-JRK/JRE-specific libraries in there. It is recipe for portability trouble as well. When compiling classes with javac, you should use the -cp argument to specify the dependent libraries.

Update: in case of an IDE (you seem to use one as you're talking about "build path"), you need to associate the web project with an application server. In Eclipse for example, you have the option to do that during creation of a Dynamic Web Project. You need to integrate the server instance in Eclipse prior to project creation. You can do that through the Servers view (assuming that you're using Eclipse for Java EE developers, else upgrade). You can also change it afterwards through the Servers entry in the project properties. Choose one which you'd like to use as the "default" server and then its libraries will automatically be included in the project's build path. There's absolutely no need to copy/move them somewhere else. See also How do I import the javax.servlet API in my Eclipse project?

Community
  • 1
  • 1
Dzmitry Alifer
  • 409
  • 1
  • 6
  • 17