在tomcat編譯時正常，而運行期時拋錯，錯誤會顯示Cause by:java.lang.NoClassDefFoundError:
Lorg/apache/commons/logging/Log
在JAVA開發中，main線程中拋出java.lang.NoClassDefFoundError是一個非常普遍且比較難解決的問題。解決這個問題的複雜性主要取決於你的軟件大小和中間件部署情況，尤其要考慮在應用中出現的數量衆多的classloader的情況。 本文將從一個比較高的角度看這個問題，主要是介紹java classloader機制。 我們先簡單的看一下這個問題，這個runtime異常是JVM拋出的，當JVM發現一個classloader試圖去Load一個class，而此class在當前的classloader tree中找不到的時候，就會拋出此異常。 很明顯，這個問題是運行期的問題，在編譯期一切正常。 ok，到這裏還不行，這個問題解決起來不是那麼容易的，在運行期的程序classpath中加入缺少的jar包僅僅是一種解決方法。關鍵是，我們必須掌握此種異常的根本原因，以後解決此問題就可以以不變應萬變。這就是我寫這個文章的初衷。 現在，先記住，此問題不一定是由於在classpath中缺少class的定義。 java classloader概述 在深入分析之前，我們必須掌握java classloader的基本原理。class loader是一個java對象，它負責load所有的class，負責查找、加載、生成一個class的基本定義信息。classloader自身採用了委託代理機制來查詢class，每一個classloader的實例都有一個父classloader，所以，當一個應用的classloader去加載class A的時候，首先發生的事情是classloader委託其父classloader去加載class A，經過一串鏈式查找後，最終任務會落在JVM的系統啓動classloader上。 那哪裏會出問題？當你期望你的應用classloader能加載class A，但是當class A被其任意一個父classloader查詢到並加載，那麼就可能會出現java.lang.NoClassDefFoundError。當所有的父classloader都找不到class A的時候，纔會由應用自己的classloader嘗試加載。
最後總結就是少了commons-logging-1.0.4.jar包
