Maven下java.lang.NoClassDefFoundError

最新推荐文章于 2025-03-25 14:11:38 发布

早晨6：30

最新推荐文章于 2025-03-25 14:11:38 发布

阅读量1.7k

点赞数

分类专栏： maven 异常文章标签： maven 异常

异常同时被 2 个专栏收录

2 篇文章

订阅专栏

maven

1 篇文章

订阅专栏

本文转载自：http://blog.youkuaiyun.com/qqhjqs/article/details/51491516

使用maven管理web项目中jar包之间的依赖，非常的方便好用，但是有时也会出现问题

项目里用net.sf.json
使用maven配置了以下jar包

jakarta commons-lang 2.5  
jakarta commons-beanutils 1.8.0  
jakarta commons-collections 3.2.1  
jakarta commons-logging 1.1.1  
ezmorph 1.0.6

如果将以上的jar包放在非maven管理的项目里的lib下，不会出现任何问题
但是在maven下，当代码跑到
JSONObject.from(str)的时候，控制台报错，错误内容如下：

java.lang.NoClassDefFoundError: org/apache/commons/lang/exception/NestableRuntimeException  
    at java.lang.ClassLoader.defineClass1(Native Method)  
    at java.lang.ClassLoader.defineClass(Unknown Source)  
    at java.security.SecureClassLoader.defineClass(Unknown Source)  
    at org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2496)  
    at org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:860)  
    at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1302)  
    at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1167)  
    at com.iquant.simulated.messaging.StrategyManageTopicListener.processMessage(StrategyManageTopicListener.java:13)  
    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)

刚开始我以为是包没有下载成功，或者是版本不对，当时按着这个思路，搞了大半天，确定jar包都下载了，版本也都对。
突然想到，将字符串抽出来，在main方法里跑一下，看是否成功，结果和我想的一样，是成功的，那也就是说在web运行的过程中
"找不到相关的包"
按照这个思路走了下去各种百度各种查。

然后我去tomcate发布目录下将项目的web-inf里的lib打开
查看里面有没有包含找不到的包---没有
然后看了看pom.xml配置文件commons-lang的配置语句

<dependency>  
    <groupId>commons-lang</groupId>  
    <artifactId>commons-lang</artifactId>  
    <version>2.6</version>  
    <scope>provided</scope>  
</dependency></span>

<scope>provided</scope> 去掉之后成功！

总结了以下，关于maven下的项目，如果出现jar包的问题，应该这样查

是否下载完整---可以将该jar包坐在的文件，删除重新下载
是否版本一致---可以全局定义一个version，下载相关使用version
是否被打包---查看tomcat文件下对应项目中的webinf-lib下有没有对应的jar包，然后在看看pom.xml中是怎样配置的

maven对jar包使用的范围有一些规定

即在jar包配置的后面添加<scope>[compile ,provided,runtime,test,system ]</scope>

名称	解释
compile （编译范围）	compile是默认的范围；如果没有提供一个范围，那该依赖的范围就是编译范围。编译范围依赖在所有的classpath 中可用，同时它们也会被打包。
provided （已提供范围）	provided 依赖只有在当JDK 或者一个容器已提供该依赖之后才使用。例如，如果你开发了一个web 应用，你可能在编译classpath 中需要可用的Servlet API 来编译一个servlet，但是你不会想要在打包好的WAR 中包含这个Servlet API；这个Servlet API JAR 由你的应用服务器或者servlet 容器提供。已提供范围的依赖在编译classpath （不是运行时）可用。它们不是传递性的，也不会被打包。
runtime （运行时范围）	runtime 依赖在运行和测试系统的时候需要，但在编译的时候不需要。比如，你可能在编译的时候只需要JDBC API JAR，而只有在运行的时候才需要JDBC驱动实现
test （测试范围）	test范围依赖在一般的编译和运行时都不需要，它们只有在测试编译和测试运行阶段可用。
system （系统范围）	system范围依赖与provided 类似，但是你必须显式的提供一个对于本地系统中 JAR 文件的路径。这么做是为了允许基于本地对象编译，而这些对象是系统类库的一部分。这样的构件应该是一直可用的，Maven 也不会在仓库中去寻找它。如果你将一个依赖范围设置成系统范围，你必须同时提供一个 systemPath 元素。注意该范围是不推荐使用的（你应该一直尽量去从公共或定制的 Maven 仓库中引用依赖）。