I am trying to deploy a war that i didnt write and i am getting this error in my logs:
java.lang.NoClassDefFoundError: HttpSessionListener
i know that HttpSessionListener lives in servlet-api.jar which is found in the lib dir of tomcat(my app server).
I tried including servlet-api.jar in the war's WEB-INF/lib folder, but the logs yelled at me for doing that:
INFO: validateJarFile(/home/test/apache-tomcat-6.0.18/webapps/test/WEB-INF/lib/servlet-api.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class
the internets claim that you dont have to include that class in your lib folder.
edit:
i removed the offending listener (which was causing the problem above) from web.xml because it didnt look very important. this revealed more errors:
java.lang.Error: Unresolved compilation problem:
The type javax.servlet.FilterChain cannot be resolved. It is indirectly referenced from required .class files
what am i missing?
Though the question is too old will tell about a possible problem nowadays. As per the Tomcat 10 download page:
Users of Tomcat 10 onwards should be aware that, ..., the primary package for all implemented APIs has changed from javax.* to jakarta.*. This will almost certainly require code changes to enable applications to migrate from Tomcat 9 and earlier to Tomcat 10 and later.
So use Tomcat 9 instead of 10.
#BalusC's explanation sounds more plausible than mine ...
Some other possible explanations / things to check:
The servlet-api.jar is not in $CATALINA_HOME/lib, or for some reason doesn't contain the class. (I know you said you "know" it's there, but you didn't specifically say you checked it.)
Something else is broken which caused the first attempted load of HttpSessionListener to fail with an uncaught exception during static initialization. (This is kind of implausible, since HttpSessionListener is an interface. But it is worth checking the logs for earlier class loading errors ... just in case.)
The missing class might be named foo.bar.HttpSessionListener rather than javax.servlet.http.HttpSessionListener. This is likely to show up in the nested stack trace.
If something in the WAR you are deploying is creating its own classloader, it is possible that is is doing this incorrectly and the HttpSessionListener class is not on the classloader's effective classpath.
EDIT
If you are now seeing unresolved compilation errors reported in the logs, you should be suspecting the WAR file and the process used to build it. Specifically, it sounds like the WAR includes classes that had Java compilation errors!
(Or maybe this is a problem compiling JSPs ... but that would show up in the logs too.)
As per its javadoc that class was introduced in Servlet API version 2.3.
If you're receiving this error, then it can have basically three causes:
Your web.xml is declared as Servlet 2.2 or lower (or incorrectly declared; Tomcat may fall back to least compatibility modus). Since you're using Java EE 5 and thus Servlet 2.5, the web.xml should then be declared like as:
<web-app
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
id="YourWebAppID" version="2.5">
Your servletcontainer doesn't support Servlet 2.3 at all and will fall back to least compatibilty modus. But this can be excluded since Tomcat 6 should support Servlet 2.5.
You actually have another Servlet API JAR file of an ancient version in the classpath which is taking precedence in classloading. Since you already excluded WEB-INF/lib the next places to look would be JRE/lib and JRE/lib/ext folders.
Update: as per your edit, FilterChain was also introduced in Servlet API version 2.3.
1 + 1 = ... :)
java.lang.NoClassDefFoundError: javax/servlet/ServletContextListener for this NoClassDefFoundError on HttpSessionListener , ServletListener , ServletContextListener, etc. can be caused by a custom classloader like Sysdeo DevLoader (when using it with Eclipse) in you Context definition in the Tomcat’s server.xml file.
<Loader classname="org.apache.catalina.loader.DevLoader"
reloadable="true" debug="1" />
there.....insted of this use...
<Loader classname="org.apache.catalina.loader.DevLoader"
reloadable="true"
debug="1" useSystemClassLoaderAsParent="false"/>
and add DevLoader.jar to ur class path
Related
The library I'm maintaining contains a implementation of ServletContainerInitializer which is declared in META-INF/services/javax.servlet.ServletContainerInitializer file.
This library is used by web applications running on Tomee 8 (Apache Tomcat (TomEE)/9.0.63 (8.0.12)).
Recently I added the log4j-web dependency to the project. Before that my initializer was called as expected but since it is ignored.
After creating a minimal example I identified that my jar is ignored because :
Its name starts with spring- (it is not a library of the Spring Framework, only a poor naming choice) and,
Another jar in the classpath (log4j-web) contains a web-fragment.xml with "ordering" before or after "others" :
<web-fragment xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-fragment_3_0.xsd"
version="3.0" metadata-complete="true">
<name>my_web_fragment_xxx</name>
<distributable />
<ordering>
<before>
<others />
</before>
</ordering>
</web-fragment>
I activated Tomcat traces logs and noticed that "spring" is listed in some exclusion prefixes as well as many other names.
TRACE [Thread-2] org.apache.openejb.config.NewLoaderLogic.readDefaultExclusions Loaded default.exclusions
TRACE [Thread-2] org.apache.openejb.config.NewLoaderLogic.logExclusions Exclusion prefixes: [
...
TRACE [Thread-2] org.apache.openejb.config.NewLoaderLogic.logExclusions -snappy-java-
TRACE [Thread-2] org.apache.openejb.config.NewLoaderLogic.logExclusions -spring-
TRACE [Thread-2] org.apache.openejb.config.NewLoaderLogic.logExclusions -sshd-
...
I noticed that "google" is listed too and when I prefix my jar with "google-" it reproduces the same issue.
The default exclusion list comes from openejb-core library :
https://github.com/apache/tomee/blob/c0928e2aed1713d16d28bffaed11ad5024bc3728/container/openejb-core/src/main/resources/default.exclusions
Workarounds
Rename the library (but it will have an impact on applications depending on it),
Add the name of the ignored jar to the tomcat.util.scan.StandardJarScanFilter.jarsToScan jars list (but it has to be done to every environments from dev to production for customers using our products).
Question
What I would like to understand is, why this issue is only triggered when a jar in the classpath contains a web-fragment with an <ordering> element ?
Minimal reproducible sample
https://github.com/KWSimon/tomcat_jarscanning
When deploying a Springboot maven project(version 2.3.4.RELEASE) to an external Tomcat container,official guide says you need to mark the "spring-boot-starter-tomcat" dependency as provided ,but actually even if without doing that,the final war package which contains lib like "spring-boot-starter-tomcat","tomcat-embed-core" and "tomcat-embed-websocket" also works fine in tomcat8.5.54 or tomcat 9.0 ,so I am confused about that,"Do we really need set spring-boot-starter-tomcat as provided or not?" ,anyone could explains why?
"Traditional Deployment"
You don't want to have multiple versions of the same classes on the classpath. This can lead to many errors during runtime. For example, if you have a
public class MyServlet implements javax.servlet.Servlet
and you package both MyServlet.class and javax.servlet-api.jar (which contains javax.servlet.Servlet) into your application, you might get an error:
Servlet class MyServlet is not a javax.servlet.Servlet
What happens is: when the application classloader loads MyServlet, it looks for javax.servlet.Servlet in the application first and it finds it in javax.servlet-api.jar. The server compares this class with the one loaded by the server's classloader and concludes that they differ, since classes from different JARs are not equal. If the application is shipped without javax.servlet-api.jar this does not happen: the classloader does not find javax.servlet.Servlet in its own classpath, so it looks in the parent classloader.
Remark: This example can not actually be reproduced on Tomcat. Due probably to many incorrectly packaged applications the WebappClassLoader has an exception to the class loading rule: special classes such as those starting with javax.servlet or org.apache.tomcat are always loaded from the server's classloader (cf. the source code for a list of these exceptions).
TL;DR: due to the remark above, leaving spring-boot-starter-tomcat in the compile scope probably will do no harm, but it is a risk not worth taking.
We are integrating an internal framework into our weblogic application and we are running into deployment problems.
Technologies Used
Weblogic 10.3.6 application
Spring 3.0
Maven 2
Eclipse J2EE
The Problem
On startup of the weblogic application, we receive the following NoSuchMethodError while initializing one of the beans. This error is occuring when calling classes in the org.joda.time (2.0) jar.
Caused By: java.lang.NoSuchMethodError: org.joda.time.DateTimeZone.convertLocalToUTC(JZ)J
at org.joda.time.LocalDate.toDateTimeAtStartOfDay(LocalDate.java:715)
at org.joda.time.LocalDate.toDateTimeAtStartOfDay(LocalDate.java:690)
. . . excluded . . .
Things We Have Tried
After Googling "NoSuchMethodError spring", many of the problems seem to be incompatible Spring versions. After printing the dependency tree, the only Spring version in use is 3.0.
Googling "NoSuchMethodError" usually gave JAR hell solutions.
Multiple versions of the same dependency. After doing some maven dependency management, the only joda-time jar in use is 2.0. Additionally, the local repository was purged of any unnecessary jars.
.war / runtime may not have the correct jars included in the lib directory. After looking into the WEB_INF/lib directory, the only joda-time jar is version 2.0, which contains all of the appropriate class files
One mysterious thing is that the DateTimeZone.convertLocalToUTC(JZ)J has been a part of the org.joda.time project since 1.0, so even if we have incompatible versions, the method should still be found, especially if the class and package are able to be found.
Finally there are no other DateTimeZone classes in the project (ctrl+shift+T search in eclipse) so I'm confused as to which class is being loaded if the org.joda.DateTimeZone class is not being loaded.
Questions:
Can anyone explain why the method could not be found?
Are there more places to check for existing or conflicting jars?
Is there a way to check the DateTimeZone class that the LocalDate class is using during runtime via Eclipse debug?
Here's some interesting reading:
prefer-web-inf-classes Element
The weblogic.xml Web application deployment descriptor contains a
element (a sub-element of the
element). By default, this element is set to
False. Setting this element to True subverts the classloader
delegation model so that class definitions from the Web application
are loaded in preference to class definitions in higher-level
classloaders. This allows a Web application to use its own version of
a third-party class, which might also be part of WebLogic Server. See
“weblogic.xml Deployment Descriptor Elements.”
taken from: http://docs.oracle.com/cd/E15051_01/wls/docs103/programming/classloading.html
Other troubleshooting tips:
You can try: -verbose:class and check your managed server's logs to check if the class is being loaded properly.
An efficient way to confirm which intrusive jar might be getting loaded is by running a whereis.jsp within the same webcontext (i.e., JVM instance) of this app.
--whereis.jsp --
<%# page import="java.security.*" %>
<%# page import="java.net.URL" %>
<%
Class cls = org.joda.time.DateTimeZone.class;
ProtectionDomain pDomain = cls.getProtectionDomain();
CodeSource cSource = pDomain.getCodeSource();
URL loc = cSource.getLocation();
out.println(loc);
// it should print something like "c:/jars/MyJar.jar"
%>
You can also try jarscan on your $WEBLOGIC_HOME folder to see if you can find the jar that contains this class: https://java.net/projects/jarscan/pages/Tutorial
A NoSuchMethodError is almost always due to conflicting library versions. In this case I'm guessing there are multiple versions of joda libraries in the two projects.
Weblogic is pulling the org.joda jar.
Tryu adding this in your weblogic.xml to exclude the jar that weblogic is pulling, and instead use your appllication jar.
The below is from my application, you can have a look what all we have to removed for our application.
<wls:container-descriptor>
<wls:prefer-application-packages>
<wls:package-name>antlr.*</wls:package-name>
<wls:package-name>org.slf4j.*</wls:package-name>
<wls:package-name>org.slf4j.helpers.*</wls:package-name>
<wls:package-name>org.slf4j.impl.*</wls:package-name>
<wls:package-name>org.slf4j.spi.*</wls:package-name>
<wls:package-name>org.hibernate.*</wls:package-name>
<wls:package-name>org.springframework.*</wls:package-name>
<wls:package-name>javax.persistence.*</wls:package-name>
<wls:package-name>org.apache.commons.*</wls:package-name>
<wls:package-name>org.apache.xmlbeans.*</wls:package-name>
<wls:package-name>javassist.*</wls:package-name>
<wls:package-name>org.joda.*</wls:package-name>
<wls:package-name>javax.xml.bind.*</wls:package-name>
<wls:package-name>com.sun.xml.bind.*</wls:package-name>
<wls:package-name>org.eclipse.persistence.*</wls:package-name>
</wls:prefer-application-packages>
<wls:show-archived-real-path-enabled>true</wls:show-archived-real-path-enabled>
</wls:container-descriptor>
I am getting the following error when deploying an application on JBoss 4.2.1
7:05:59,673 ERROR [Application Name]StandardWrapper.Throwable
java.lang.IllegalStateException: Application was not properly initialized at
startup, could not find Factory: javax.faces.context.FacesContextFactory
I browsed the net and I found many posts which suggested to add an entry in web.xml but that entry was already there. And all the required libraries are there in web-inf.
So any solutions anybody ?
Ensure that your classpath is clean (i.e. no duplicate different versioned classes/JAR files, keep in mind that JBoss ships with builtin JSF libraries!) and that your web.xml is declared as at least Servlet 2.3.
Im getting a weird error when running my spring2.5.6,jpa(hibernate3.4) webapp in weblogic 10.3
[ERROR] Javassist Enhancement failed: com.xxx.domain.model.Scheme
java.lang.NoSuchMethodError: pcGetManagedFieldCount
at com.xxx.domain.model.Fund.<clinit>(Fund.java)
at sun.misc.Unsafe.ensureClassInitialized(Native Method)
at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAc
cessorFactory.java:25)
The com.xxx.domain.model.Scheme class is a mapped subclass entity of the abstract fund entity on a single_table inheritance hierarchy, and I'm getting this error for all entities on the hierarchy. I'm using both annotated classes and xml metadata to define the mappings for my persistence classes.
I only get this error when the app is deployed to weblogic, so everything runs fine using junit. I have tried upgrading to the latest version on javaassit.jar.
Problem Looks to me like an issue with classloading order, but I cant figure it out.
PS. As suggested by bea I have added the following to the weblogic.xml
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
Anyone got any ideas, other config tips, or directions I should take my investigation?
I had the same problem.
My entities extended a class (#MappedSuperClass) which lived inside a jar dependency. I had to move that class from the jar into my project. Only then it would work and deployed fine.
Also another way to solve this is to specify your entities explicitly in the persistence.xml
I'm sorry, I only have WebLogic 10.0 on my machine, and it doesn't have any javassist JARs in the distro. Looks like javassist was only added in 10.3 for AOP byte code generation.
It might be worth a try to remove the javassist JAR from your WebLogic deployment and use the version that it supports. Take the "prefer-web-inf-classes" tag out of your web.xml and see if it can work with the version that WebLogic prefers.
Can you post the code for the entity class and, if you're not using annotations, the segment of your hbm mapping file?
Your classpath hunch may be right on. In your weblogic-application.xml, try this
<prefer-application-packages>
<package-name>antlr.*</package-name>
<package-name>org.antlr.*</package-name>
</prefer-application-packages>
If you have any more log output, please post that as well.
I just lost a couple of days on this myself. The problem for me was that I 2 separate data-services modules in my app. I'm thinking 10.3 has some trouble with that. I'm not sure of the solution, but a work around for me was to combine both of my data-services modules into just one.
BEA seems to be aware of this issue. Hopefully the URL below will help. Reference CR370788.
http://edocs.bea.com/wls/docs103/issues/known_resolved.html