java.lang.NoClassDefFoundError的：Apache的Tomcat的7.0.25 [英] java.lang.NoClassDefFoundError: apache-tomcat-7.0.25

问题描述

在部署我的应用程序，以我现在面临以下错误Tomcat服务器：

  2013年6月14日7时54分36秒ErrorLogger [错误]作业（DEFAULT.NearByRioDeJaneiro引发了异常。
org.quartz.SchedulerException：作业引发了未处理的异常。 [见嵌套异常：java.lang.NoClassDefFoundError的：无法初始化类com.frrole.service.common.OAuthUtil]
    在org.quartz.core.JobRunShell.run（JobRunShell.java:224）
    在org.quartz.simpl.SimpleThreadPool $ WorkerThread.run（SimpleThreadPool.java:557）
java.lang.NoClassDefFoundError的：引起无法初始化类com.frrole.service.common.OAuthUtil
    在com.frrole.service.common.City._getTweetsByQueryObj（City.java:357）
    在com.frrole.service.common.City.getTweetsByGeoLocSearch（City.java:340）
    在com.frrole.service.api.TwitterSearch.nearbyLocationSearch（TwitterSearch.java:148）
    在com.frrole.service.imports.jobs.NearByRioDeJaneiro.execute（NearByRioDeJaneiro.java:14）
    在org.quartz.core.JobRunShell.run（JobRunShell.java:213）
 

因为它可以从这个错误中可以观察到日志的主要问题是不能够找到tomcat的： com.frrole.service.common.OAuthUtil 类。这个类是由类中的方法 _getTweetsByQueryObj 引用 com.frrole.service.common.City 。因此，当某个地方执行这种方法，Tomcat是无法找到OAuthUtil类。该OAuthUtil类在其code定义正确的包语句。该应用程序还编译成功，否则ws.war不会被生产。

混乱的部分是， OAuthUtil 类是在同一包（和目录）为城市类。下面是在Tomcat中的webapps文件夹的目录WS目录树中的 LS 。

<$p$p><$c$c>root@servicesfrrole3:/usr/tomcat/apache-tomcat-7.0.25/webapps/ws/WEB-INF/classes/com/frrole/service/common# ls -l命令
总88
-rw-R - R-- 1根根12284 2013年6月14日13:15 City.class
-rw-R - R-- 1根根21350 2013年6月14日13:15 DBUtil.class
-rw-R - R-- 1根根1064 2013年6月14日13:15 Messages.class
-rw-R - R-- 1根根2026 2013年6月14日13:15 OAuthUtil $ _AccessToken.class
-rw-R - R-- 1根根2741 2013年6月14日13:15 OAuthUtil.class
-rw-R - R-- 1根根1710 2013年6月14日13:15 ReTweet.class
-rw-R - R-- 1根根1431 2013年6月14日13:15 SQLUtils.class
-rw-R - R-- 1根根6397 2013年6月14日13:15 TimeAgo.class
-rw-R - R-- 1根根3363 2013年6月14日13:15 Tweet.class
-rw-R - R-- 1根根3730 2013年6月14日13:15 TweetUtil.class
-rw-R - R-- 1根根5982 2013年6月14日13:15 TweetVO.class
-rw-R - R-- 1根根1328 2013年6月14日13:15 TwitterResults.class
-rw-R - R-- 1根根1941年2013年6月14日13:15 ViaTweet.class

因为它可以观察到，显然是有OAuthUtil.class驻留在同一目录City.class 。在code编译正确和完美的运行在本地主机拥有的Java 7和Tomcat 7.0.40。该服务器的Java 7和服务器的Tomcat 7.0.25。

在部署应用程序，我只是将其编译在本地主机上，并复制文件ws.war到服务器，然后从previous WS应用程序文件夹的RM -r的webapps目录下，最后重新启动服务器。

如果任何人有这里发生了什么的任何解释，请提供一些解决方案。

解决方案

线索是在异常的消息：

 无法初始化类com.frrole.service.common.OAuthUtil
 

什么实际发生的情况是出现了错误的 previously 的一些类初始化。 （也许 OAuthUtil 类本身，或者一些其他类，这取决于）。如果通过日志文件回头看，你应该看到例外。

现在你已经执行了一些code，它依赖于类previously初始化失败。结果是这样的例外。

如果你不能找到你的日志文件中的previous例外，它可能是由于异常被挤压，或者当某个线程死了，因为你的应用程序没有定义默认的未捕获异常丢失处理程序。

While deploying my application to a tomcat server I'm facing following errors:

2013-06-14 07:54:36 ErrorLogger [ERROR] Job (DEFAULT.NearByRioDeJaneiro threw an exception.
org.quartz.SchedulerException: Job threw an unhandled exception. [See nested exception: java.lang.NoClassDefFoundError: Could not initialize class com.frrole.service.common.OAuthUtil]
    at org.quartz.core.JobRunShell.run(JobRunShell.java:224)
    at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557)
Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.frrole.service.common.OAuthUtil
    at com.frrole.service.common.City._getTweetsByQueryObj(City.java:357)
    at com.frrole.service.common.City.getTweetsByGeoLocSearch(City.java:340)
    at com.frrole.service.api.TwitterSearch.nearbyLocationSearch(TwitterSearch.java:148)
    at com.frrole.service.imports.jobs.NearByRioDeJaneiro.execute(NearByRioDeJaneiro.java:14)
    at org.quartz.core.JobRunShell.run(JobRunShell.java:213)

As it can be observed from this error log the main problem is with tomcat not being able to locate: com.frrole.service.common.OAuthUtil class. This class is referenced by the method _getTweetsByQueryObj in class com.frrole.service.common.City. Hence, somewhere while executing this method, tomcat is unable to locate OAuthUtil class. The OAuthUtil class has proper package statement defined in its code. The application also compiles successfully otherwise ws.war would not have been produced.

The confusing part is that OAuthUtil class is in same package (and directory) as City class. Below is a ls of directory tree in ws directory of tomcat's webapps folder.

root@servicesfrrole3:/usr/tomcat/apache-tomcat-7.0.25/webapps/ws/WEB-INF/classes/com/frrole/service/common# ls -l
total 88
-rw-r--r-- 1 root root 12284 2013-06-14 13:15 City.class
-rw-r--r-- 1 root root 21350 2013-06-14 13:15 DBUtil.class
-rw-r--r-- 1 root root  1064 2013-06-14 13:15 Messages.class
-rw-r--r-- 1 root root  2026 2013-06-14 13:15 OAuthUtil$_AccessToken.class
-rw-r--r-- 1 root root  2741 2013-06-14 13:15 OAuthUtil.class
-rw-r--r-- 1 root root  1710 2013-06-14 13:15 ReTweet.class
-rw-r--r-- 1 root root  1431 2013-06-14 13:15 SQLUtils.class
-rw-r--r-- 1 root root  6397 2013-06-14 13:15 TimeAgo.class
-rw-r--r-- 1 root root  3363 2013-06-14 13:15 Tweet.class
-rw-r--r-- 1 root root  3730 2013-06-14 13:15 TweetUtil.class
-rw-r--r-- 1 root root  5982 2013-06-14 13:15 TweetVO.class
-rw-r--r-- 1 root root  1328 2013-06-14 13:15 TwitterResults.class
-rw-r--r-- 1 root root  1941 2013-06-14 13:15 ViaTweet.class

As it can be observed, clearly there is a OAuthUtil.class residing in the same directory as City.class. The code compiles properly and runs perfectly on localhost which has Java 7 and Tomcat 7.0.40. The server has Java 7 and Tomcat 7.0.25 on server.

While deploying application, I'm simply compiling it on localhost and copying the ws.war file into webapps directory of server followed by rm -r of ws folder from previous application and finally restarting the server.

If anyone has any explanation of what is happening here, please provide some solution.

解决方案

The clue is in the exception message:

"Could not initialize class com.frrole.service.common.OAuthUtil"

What has actually happened is that an error has occurred previously in some class initializer. (Maybe the OAuthUtil class itself, or maybe some other class that it depends on.) If you look back through the log file, you should see the exception.

Now you have executed some code that depends on that class that previously failed initialization. The result is this exception.

If you can't find the previous exception in your log files, it is probably due to the exception being "squashed", or being lost when some thread died because your application hasn't defined a default uncaught exception handler.

这篇关于java.lang.NoClassDefFoundError的：Apache的Tomcat的7.0.25的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！