發(fā)現(xiàn)一個問題，使用struts進行文件上傳，如果有些參數(shù)沒有完全定義在ActionForm中，需要從request.getParameter獲取，在表單提交并且validate失敗返回input頁面時，這部分需要從request.getPrameter獲取的參數(shù)數(shù)據(jù)都丟失了，即使再對request進行multipart解析也不能得到。

     經(jīng)過分析，發(fā)現(xiàn)struts的ActionServlet在接收到multipart請求之后，在RequestProcessor中會對request進行封裝：MultiRequestWrapper，然后在Action執(zhí)行完之后，又將已經(jīng)封裝的request重新還原。以下是部分代碼，截直RequestProcessor：

封裝：

還原：
   在doForward和doInclude中在forward和include之前都執(zhí)行了下面的代碼：


     問題就出現(xiàn)在這兒。在經(jīng)過測試之后，發(fā)現(xiàn)request只能進行一次multipart解析，這或許和解析request的時候調(diào)用了request.inputStream有關(guān)，第一次調(diào)用之后再調(diào)用就不能獲取其中的有效內(nèi)容了。因此發(fā)現(xiàn)request在調(diào)用CommonsMultipartRequestHandler.handleRequest進行解析后并還原后，調(diào)用common-upload對request進行解析已經(jīng)得不到任何得提交內(nèi)容了，因此當(dāng)Form驗證失敗，返回input頁面時，即使再進行multpart解析，也不能通過request.getPrameter取到你想要的數(shù)據(jù)。而此時，表單中的數(shù)據(jù)卻不會丟失（定義在ActionForm中的表單域），這是因為struts的html系列tag在redisplay時值都是從ActionForm獲取的。

       在將RequestProcessor.doForward和doInclude中還原request的語句注釋后，問題得到了解決。到目前還不清楚為什么struts要還原request，難道是因為chain的原因？

       webwork中應(yīng)該不會出現(xiàn)這個問題，因為webwork中無論ServletDispatcher還是FilterDispatcher在對request wrap之后都沒有再還原。 tomcat、jdk1.4下出現(xiàn)The output format must have a '{http://xml.apache.org/xalan}content-handler' property!的原因：
    這是因為系統(tǒng)、tomcat或者jdk使用了老版本的xalan.jar。系統(tǒng)如果本身沒有使用，而tomcat/common/lib、tomcat/common/endorsed/lib、tomcat/shared/lib下又沒有xalan.jar的話，那就是jdk使用了老版本的xalan.jar——在jre\lib\rt.jar里面。下載最新的xalan.jar然后放到tomcat/common/endorsed下即可解決這一問題。 暫時記下，沒想透徹，思考所得、個人見解以后再加入。

企業(yè)發(fā)展的4個階段：

產(chǎn)品階段

資產(chǎn)階段

資本階段

品牌階段

企業(yè)管理的4個階段：

人治，嘴上說

法治，建立制度

企業(yè)文化

目標(biāo)管理，充分發(fā)揮員工的積極主動型，自我管理

 

      blog很好，blogjava暫時感覺也很好，可是為什么不能寫只允許自己看的日志呢？雖說blog就是為了大家能夠分享彼此的觀點感想，但是總有一些東西是不便公開或者暫時不能公開的。如果允許寫只允許自己看的日志，blog的應(yīng)用范圍就會更大，價值也會被充分挖掘了。
     也可能是我愚昧，對blog了解還不深吧，上述所說的blog也許已經(jīng)出現(xiàn)了（自己搞一個得了，笑談）。

XP

SCRUM
需要并且應(yīng)該持續(xù)關(guān)注、思考。

一些共同點：

快速迭代

持續(xù)改進

注重測試

團隊協(xié)作

       很久沒有來這兒了。其實我很喜歡BLOG，可以記下每天工作中的所思所想。我是一個喜歡思考的人，經(jīng)常有一些想法，有這么一塊地方，能夠把自己的經(jīng)驗、想法、創(chuàng)造記錄下來，沉積起來，對自己無疑是一種財富。

      不知道是不是有人會寫項目經(jīng)理日志，我覺得這是一個很好的事情。以前做項目管理的時候只是弄了一個“項目事件”，記錄項目開發(fā)過程中發(fā)生的、自己覺得是重要的事情，比如某某人進入項目組、離開項目組了，某某模塊版本發(fā)布了，發(fā)生了什么大的費用等等。寫項目經(jīng)理日志，或者開發(fā)日志、工作日志也行，把自己在工作中、項目開發(fā)過程中、項目管理過程中的零零碎碎的想法記錄下來，會是一件很棒的事情。人不應(yīng)該懶，再累心情再遭也應(yīng)該堅持寫這種日志。

      或許小筆記本、那種可以隨身攜帶的那種是一件更好的日志記錄工具，可惜容量不夠，而且不能檢索。掌上電腦？寫起來似乎麻煩了，table-pc，好像又太大了，攜帶不方便，可惜，要是手寫識別技術(shù)更智能一點、掌上電腦更薄一點，而且可以展開屏幕就棒了。可惜。

 

　　JDK1.5出來很久了，一直沒有研究。這倒不是沒有時間，而是覺得J2EE服務(wù)器要支持JDK1.5還需要一段時間，而多數(shù)客戶還在使用JDK1.4，因此要基于JDK1.5開發(fā)Web應(yīng)用程序還不現(xiàn)實，因此一直沒有去弄這玩意。

　　今天由于研究Desktop的開發(fā)，裝了1.5，發(fā)現(xiàn)1.5中Java程序已經(jīng)可以獲得本地系統(tǒng)的外觀，我試著不斷的變換了xp的theme，Java程序始終能夠保持和系統(tǒng)的外觀一致；而且以前使用SkinLF后，在web start程序中JOptionPane的窗體經(jīng)常出不來的問題也解決了。這可是一個非常好的消息。

　　另一個好消息是JDK的下一個版本將對Swing/AWT組件進行增強。

　　為Java感到高興！

這里列出一部分Java Desktop的開發(fā)資源。

1。A java.net community for JavaDeskTop

　　這是sun主持的資源很全的社區(qū)，有很多關(guān)于JavaDeskTop開發(fā)的資源。

2。JDIC（Java Desktop Integration Components）

　　Sun主持的致力于java和本地應(yīng)用程序集成、交互的組件集，非常棒。目前有5大組件。

　　Desktop

　　FileTypes

　　Brower

　　System Tray Icon

　　Packager

3。JDNC（Java Desktop Network Component）

4。JExePack

　　一個將Java程序轉(zhuǎn)化為Exe程序的組件。

5。JSmooth

　　作用同JExePack。

6。JavaService

　　一個將Java程序轉(zhuǎn)化為NT Service的組件。

7。SKinLF

　　非常棒的Java LookAndFeel實現(xiàn)，采用配置包的形式定義Java的LookAndFeel，可以很方便的定義自己的LookAndFeel。它的網(wǎng)站上提供了大量Skin下載，其中不乏精品。

8。JGoodies

　　JGoodies最出名的是它的FormLayout，它使swing和AWT應(yīng)用程序的布局變得非常簡單。由于它的影響，已經(jīng)有專門針對它的DESIGNER出現(xiàn)，Eclipse也有相應(yīng)的插件支持。FormLayout使Java的幾個默認(rèn)Layout相形見絀。

　　JGoodies還有一組Swing/Awt組件，可以很方便的創(chuàng)建Wizard、對話框、Splash窗體、About窗體等GUI部件。

9。Rachel（Open Source Resource Loading Toolkit for Java Web Start ）

　　和WebStart打過交道的人可能知道，要在webstart中讀取解析zip或者jar資源是一件非常困難的事，然而有些資源又必須以zip或者jar的形式存在，比如SKinLF就是這樣。Rachel使你不再為這種事情煩惱。它提供兩種解決方案：采用class://的協(xié)議裝載URL資源，內(nèi)嵌一個小型的多線程http server。

10。JavaHelper（JavaHelp System）

　　Sun提供的制作Java Help制作系統(tǒng)。允許你在GUI應(yīng)用程序、Applet中提供Online Help功能。

11。Exe4j

　　Java 安裝程序制作工具。

12。JGraph

　　非常出名的Java 圖形編輯框架。

13。GEF（Graphic Edit Framework）

　　非常好的圖形編輯框架，雖然沒有JGraph出名，但是我始終覺得它的結(jié)構(gòu)和API都比JGraph好，擴展性非常好。

14。yworks

　　它的YGuard是一個非常棒的混淆器，免費的，功能很強。除了YGuard它還有幾個非常好的組件。

15。Create GUI with JFC/Swing

　　Sun的JFC/Swing編程初學(xué)者指南。

16。Drag and Drop

　　Sun的關(guān)于在GUI中實現(xiàn)拖放操作的教學(xué)文章。

17。Joshua Marinacci的Blog

　　有很多介紹GUI編程的好文章。

18。CloseAndMaxTabbedPane An enhanced JTabbedPane

　　JavaWorld上一篇關(guān)于如何在JTabbedPane的Tab上添加Close按鈕、Maximize 按鈕和PopupMenu的文章，有源代碼下載。還可以。

19。Creating Wizard Dialogs with Java Swing

　　Sun上的介紹用Swing創(chuàng)建類似Elipse Wizard對話框的文章。

　　SkinLF（http://www.l2fprod.com/）是一個非常漂亮的Java LookAndFee組件，它的外觀可以配置，由一組小圖片和一個skinlf-themepack.xml構(gòu)成。SkinLF的網(wǎng)站上提供了很多Skin下載，這里http://www.l2fprod.com/software/skinlf/jnlp/demo.jnlp可以看到SkinLF和這些外觀的演示。可惜的是除了默認(rèn)的themepack.zip之外，其他外觀（好像有很少幾個除外）都有中文亂碼的問題。其實這是這些外觀使用的字體導(dǎo)致的。

　　打開外觀zip文件中的skinlf-themepack.xml，你會發(fā)現(xiàn)其他外觀的配置文件比themepack.zip中的配置文件多了一些地方：

　　下午，試用了SkinLF（http://www.l2fprod.com），感覺非常好，程序的外觀得到了很大的改善，還可以根據(jù)自己的需要隨意調(diào)整得到自己想要的外觀，但是要將SkinLF應(yīng)用到Web Start中還有點問題。這是因為，web start使用到的資源必須包裝成jar文件，以的形式定義到j(luò)nlp資源文件中，而SkinLF的外觀配置文件是zip形式的。也許有人會說，把zip轉(zhuǎn)化成jar文件就可以了。是的，想象中這應(yīng)當(dāng)是可以的，可是實際情況不是如此，你會發(fā)現(xiàn)使用ClassLoader.getResourceStream("themepack.jar")的時候返回了Null，SkinLookAndFeel.loadLookAndFeel()會異常Stream closed.

　　調(diào)試之后發(fā)現(xiàn)，即使是在客戶端，在Eclipse中運行的時候，如果不把themepack.jar定義到ClassPath中，也是無法加載的。

　　我想這是一個普遍的問題，根據(jù)我的理解，如果其他資源，比如圖片、xml文件、屬性文件等等能夠被加載，themepack.jar也應(yīng)該被加載。事實上應(yīng)該是這樣，但是關(guān)鍵在于SkinLF需要采用ZipInputStream解析zip（jar）文件，這時情況就不一樣了。具體的原因目前沒有搞清楚。

　　在網(wǎng)上找了半天，終于發(fā)現(xiàn)一個Open Source的組件：Rachel，使用它很輕易就可以解決上面提到的問題。

　　Rachel（http://rachel.sourceforge.net）是一個為解決Web start裝載資源困難而開發(fā)的組件。它提供了兩種方法解決資源裝載問題。

     方法一，使用class://URL Handler。
      這個方法采用新的URL協(xié)議：class://從jar文件中獲取資源。

     Step 1，注冊新的URL Handler，以支持class://協(xié)議(protocal)。
     例子：java.net.URL.setURLStreamHandlerFactory( new RachelUrlFactory() );

     Step 2，采用class://協(xié)議構(gòu)造URL，從jar文件中讀取資源。
　　語法：class:///
　　例子：

class://test.LookAndFeelTest/themepack.zip
class://com.l2fprod.gui.plaf.skin.SkinLookAndFeel/themepack.zip

　　注意：這里，是Rachel用來定義資源文件所在的jar的，后面的相對于jar中的根目錄而言。上述例子中的jar的結(jié)構(gòu)如下：

      test.jar:

      test/LookAndFeelTest.class
      com/l2fprod/gui/plaf/skin/SkinLookAndFeel.class
      themepack.zip
      images/example.png
      html/index.htm

　　Step 3，采用java.net.URL獲取資源。
      例子：

    URL url = new URL("class://test.LookAndFeelTest/themepack.zip");
    URL url = new URL("class://test.LookAndFeelTest/html/index.html");
    URL url = new URL("class://test.LookAndFeelTest/images/example.png");

    URL url = new URL("class://com.l2fprod.gui.plaf.skin.SkinLookAndFeel/themepack.zip");
    SkinLookAndFeel.setSkin( SkinLookAndFeel.loadThemePack(url) );

　　方法二，在程序中嵌入多線程的，小型的http server。

　　Step 1，把你的資源放到j(luò)ar中。

　　Step 2，在每一個jar中增加一個anchor class，幫組server定位資源所在的jar文件，這點類似于方法一class:///的的。
　　例子：

　　　public class CrossRefAnchor
　　　{
　　　　　public CrossRefAnchor() {}
　　　}

　　CrossRefAnchor沒有任何的實際意義，只是為了幫組定義資源所在的jar。

　　Step 3，為每一個包含資源的jar用ClassResourceLoader注冊到WebResourceManager。
　　例子：

　　　WebResourceManager roots = WebResourceManager.getInstance();
　　　roots.addResourceLoader( new ClassResourceLoader( CrossRefAnchor.class ) );
　　　roots.addResourceLoader( new ClassResourceLoader( JavaDocAnchor.class ) );

　　Step 4，啟動Server。
　　例子：

　　　try
　　　{
　　　　　WebServer http = new WebServer( 7272, roots );
　　　　　http.start();
　　　}
　　　catch( IOException e )
　　　{
　　　　　e.printStackTrace();
　　　}

　　Step 5，采用URL從server獲取資源。
　　例子：

　　　URL crossRefUrl = new URL( "http://localhost:7272/crossref/index.html" );
　　　URL url = new URL( "http://localhost:7272/test.LookAndFeelTest/themepack.zip" );
　　　URL url = new URL( "http://localhost:7272/test.LookAndFeelTest/html/index.html" );
　　　URL url = new URL( "http://localhost:7272/test.LookAndFeelTest/images/example.png" );

我使用的是GEF0.10(http://gef.tigris.org)，在某一個Fig上點擊鼠標(biāo)右鍵彈出PopupMenu時，發(fā)現(xiàn)有閃爍的現(xiàn)象，經(jīng)過追查發(fā)現(xiàn)，一個鼠標(biāo)右擊動作會分別觸發(fā)Editor.mousePressed(e)、mouseReleased(e)、mouseClicked(e)三個事件，這些事件最終都要流經(jīng)ModeManager，而ModeManager采取的是廣播的方式分發(fā)這些事件，把這些事件依次轉(zhuǎn)發(fā)給mode對列中的所有Mode。ModePopup是默認(rèn)的一個Mode之一，負(fù)責(zé)提供Fig的彈出菜單功能。而ModePopup中的這三個事件都作了如下的判斷： 

 

其中加紅的這段不知道為什么要作me.getModifiers() == InputEvent.BUTTON3_MASK的判斷，加上這個判斷后只要是鼠標(biāo)右擊動作，ModePopup的mousePressed、mouseReleased和mouseClicked事件中showPopup的代碼都要被執(zhí)行，這樣在一個鼠標(biāo)右擊動作中實際上彈出了三次PopupMenu，因此造成了閃爍。解決辦法是extend默認(rèn)的ModePopup，覆蓋這三個方法，將判斷改成if ( me.isPopupTrigger())即可。

今天做了一個測試，發(fā)現(xiàn)Hibernate的dynamic-update只在兩種條件下生效：

1。同一session內(nèi)，對已經(jīng)persisit的對象進行update，這里的“已經(jīng)persist”是指update之前先進行了create或者load調(diào)用。代碼示例：

將hibernate配置成show_sql=true，可以看到update產(chǎn)生的sql語句。

2。不同session之間，update傳入的對象是另一個session中的persist對象（對該對象調(diào)用了create或者load方法）。代碼示例：

如果將session2.merge(..)改成update，則會更新所有可更新的屬性。

今天在csdn上看到了一篇介紹PDCA理論在項目管理中應(yīng)用的blog，很是感慨，想想才到公司的時候老總也給我們做過相關(guān)培訓(xùn)，一年下來，要是沒有看到這篇blog，鐵定是想不起來了。PDCA（計劃、實施、檢察、優(yōu)化）是一個很好的理論，現(xiàn)摘錄這篇blog的內(nèi)容如下，以為珍藏。

以下內(nèi)容出自：http://blog.csdn.net/wwwxuhong/archive/2004/12/20/222804.aspx 

項目管理是個很大的課題
所有的事物都有其規(guī)律

項目管理的規(guī)律是什么？
前幾天看到一個理論讓我眼睛一亮，陳述如下，希望對大家有點啟發(fā)

PDCA循環(huán)是由美國統(tǒng)計學(xué)家戴明博士提出來的，它反映了質(zhì)量管理活動的規(guī)律。P（Plan）表示計劃；D（Do）表示執(zhí)行；C（Check）表示檢查；A（Action）表示處理。PDCA循環(huán)是提高產(chǎn)品質(zhì)量，改善企業(yè)經(jīng)營管理的重要方法，是質(zhì)量保證體系運轉(zhuǎn)的基本方式。

項目管理的PDCA環(huán)。
PDCA是指以下四個階段，這四個階段是環(huán)環(huán)相扣的，這個周期是周而復(fù)始的
P  Plan  計劃
D  Do    實施
C Check 檢查
A Action 總結(jié)、再優(yōu)化

不管是多大的項目，還是多小的任務(wù)，如果都用PDCA環(huán)實施，環(huán)環(huán)相扣，就可以大大提高管理的質(zhì)量，最大程度地保障項目的成功實施。

PDCA分以下八上步驟
計劃階段
    1、分析現(xiàn)狀
    2、找出問題的原因
    3、分析產(chǎn)生問題的原因
    4、找出其中的主要原因
    5、擬訂措施計劃
實施階段
    6、執(zhí)行技術(shù)組織措施計劃
檢查階段
    7、把執(zhí)行結(jié)果與預(yù)定目標(biāo)對比
總結(jié)、再優(yōu)化階段
    8、鞏固成績，進行標(biāo)準(zhǔn)化

轉(zhuǎn)貼一篇相關(guān)文章
  在企業(yè)中，通過眾多小小的變革可能實現(xiàn)對整個企業(yè)的持久改善，從而獲得巨大的成效。這在日語中叫做“改善”（kaizen），每一步都很小，這兒一個小變化，那兒一個小改進，但幾年后就能發(fā)展出完全不同的產(chǎn)品、工序或服務(wù)。
　　PDCA循環(huán)是由美國統(tǒng)計學(xué)家戴明博士提出來的，它反映了質(zhì)量管理活動的規(guī)律。P（Plan）表示計劃；D（Do）表示執(zhí)行；C（Check）表示檢查；A（Action）表示處理。PDCA循環(huán)是提高產(chǎn)品質(zhì)量，改善企業(yè)經(jīng)營管理的重要方法，是質(zhì)量保證體系運轉(zhuǎn)的基本方式。

　　PDCA循環(huán)的特點PDCA表明了質(zhì)量管理活動的四個階段，每個階段又分為若干步驟。

　　在計劃階段，要通過市場調(diào)查、用戶訪問等，摸清用戶對產(chǎn)品質(zhì)量的要求，確定質(zhì)量政策、質(zhì)量目標(biāo)和質(zhì)量計劃等。它包括現(xiàn)狀調(diào)查、原因分析、確定要因和制定計劃四個步驟。

　　在執(zhí)行階段，要實施上一階段所規(guī)定的內(nèi)容，如根據(jù)質(zhì)量標(biāo)準(zhǔn)進行產(chǎn)品設(shè)計、試制、試驗，其中包括計劃執(zhí)行前的人員培訓(xùn)。它只有一個步驟：執(zhí)行計劃。

　　在檢查階段，主要是在計劃執(zhí)行過程之中或執(zhí)行之后，檢查執(zhí)行情況，看是否符合計劃的預(yù)期結(jié)果。該階段也只有一個步驟：效果檢查。

　　在處理階段，主要是根據(jù)檢查結(jié)果，采取相應(yīng)的措施。鞏固成績，把成功的經(jīng)驗盡可能納入標(biāo)準(zhǔn)，進行標(biāo)準(zhǔn)化，遺留問題則轉(zhuǎn)入下一個PDCA循環(huán)去解決。它包括兩個步驟：鞏固措施和下一步的打算。

　　PDCA循環(huán)四階段各步驟。

　　1.PDCA循環(huán)一定要按順序進行，它靠組織的力量來推動，像車輪一樣向前滾進，周而復(fù)始，不斷循環(huán)。

　　2.企業(yè)每個科室、車間、工段、班組，直至個人的工作，均有一個PDCA循環(huán)，這樣一層一層地解決問題，而且大環(huán)套小環(huán)，一環(huán)扣一環(huán)，小環(huán)保大環(huán)，推動大循環(huán)。

　　這里，大環(huán)與小環(huán)的關(guān)系，主要是通過質(zhì)量計劃指標(biāo)連接起來，上一級的管理循環(huán)是下一級管理循環(huán)的根據(jù)，下一級的管理循環(huán)又是上一級管理循環(huán)的組成部分和具體保證。通過各個小循環(huán)的不斷轉(zhuǎn)動，推動上一級循環(huán)，以至整個企業(yè)循環(huán)不停轉(zhuǎn)動。通過各方面的循環(huán)，把企業(yè)各項工作有機地組織起來，納入企業(yè)質(zhì)量保證體系，實現(xiàn)總的預(yù)定質(zhì)量目標(biāo)。因此，PDCA循環(huán)的轉(zhuǎn)動，不是哪一個人的力量，而是組織的力量、集體的力量，是整個企業(yè)全體職工推動的結(jié)果。

　　3.每通過一次PDCA循環(huán)，都要進行總結(jié)，提出新目標(biāo)，再進行第二次PDCA循環(huán)，使質(zhì)量管理的車輪滾滾向前。PDCA每循環(huán)一次，質(zhì)量水平和管理水平均提高一步。

　　PDCA循環(huán)不僅是質(zhì)量管理活動規(guī)律的科學(xué)總結(jié)，是開展質(zhì)量管理活動的科學(xué)程序，也是一種科學(xué)管理的工作方法。它同樣可以在質(zhì)量管理活動以外發(fā)揮重要效用。

　　PDCA管理法在營銷中的運用在運用PDCA循環(huán)進行市場營銷管理方面，已經(jīng)有一些優(yōu)秀企業(yè)走在了前頭。

　　海爾集團純熟地采用PDCA管理法來實施銷售任務(wù)的計劃、組織和控制。每年年終，集團商流、各產(chǎn)品本部根據(jù)本年度的銷售額完成情況，結(jié)合各產(chǎn)品的發(fā)展趨勢及競爭對手分析等信息，制定下一年度的銷售計劃，然后將這一計劃分解至全國11個銷售事業(yè)部。銷售事業(yè)部長根據(jù)各工貿(mào)上年的完成情況、市場狀況分析等信息再將銷售額計劃分解至其下屬各工貿(mào)公司。工貿(mào)公司總經(jīng)理將任務(wù)分解至各區(qū)域經(jīng)理，由他們將任務(wù)下達(dá)至區(qū)域代表，區(qū)域代表將自己的銷售額任務(wù)分解至其所管轄的營銷網(wǎng)絡(luò)。同時，海爾還從時間緯度上進行分解：年度計劃分解至月度，月度計劃分解至每日。這樣，處于管理層的每位管理者都可以對下屬每日的工作狀況進行監(jiān)督，并及時實施糾偏，最終控制每一個具體網(wǎng)點。海爾集團在新產(chǎn)品開發(fā)、新品上市等所有方面都遵循PDCA管理方法。這種做法可以保證“人人都管事，事事有人管”，避免出現(xiàn)管理的真空。

　　PDCA管理法運用于每日的事務(wù)管理，就形成了獨具海爾特色的OEC日清體系。每人均處于相應(yīng)的崗位上，每一崗位均有不同的職責(zé)，并分配相應(yīng)的指標(biāo)，員工的激勵直接與指標(biāo)掛鉤。指標(biāo)又可分為主項指標(biāo)與輔項指標(biāo)以及臨時任務(wù)指標(biāo)等。每人在當(dāng)日晚上分析一天的各項任務(wù)完成情況，并找出差距原因及糾偏辦法，以使今后的工作質(zhì)量得到提高，由此構(gòu)成了持續(xù)不斷的改進過程。員工在做完當(dāng)日總結(jié)后，對明日工作做出計劃，然后將OEC日清表交至主管領(lǐng)導(dǎo)處，由主管領(lǐng)導(dǎo)進行審核控制并對下屬的當(dāng)日工作進行評價和激勵。

　　OEC管理法的主要理念，海爾認(rèn)為是“堅持兩個原則，最大限度地對待兩種人”，即堅持閉環(huán)原則，堅持優(yōu)化原則，最大限度地關(guān)心員工的生活，最大限度地滿足用戶的需求。所謂閉環(huán)原則，指凡事要善始善終，都必須遵循PDCA循環(huán)，而且是螺旋上升。所謂優(yōu)化原則，指根據(jù)木桶理論，找出薄弱項，及時整改，提高全系統(tǒng)的水平。在一個企業(yè)的運營過程中，必然存在著許多環(huán)節(jié)，只要找出制約企業(yè)經(jīng)濟效益提高的某一關(guān)鍵環(huán)節(jié)，把首要矛盾解決了，其他矛盾就可以迎刃而解。

　　張瑞敏說，海爾生產(chǎn)線每天要出大大小小幾萬臺家電產(chǎn)品，我們不能考慮出了問題如何處理，而要追求不出任何問題。OEC管理法把質(zhì)量互變規(guī)律作為基本思想，堅持日事日清，積沙成塔，使員工素養(yǎng)、企業(yè)素質(zhì)與管理水平的提高寓于每日工作之中，通過日積月累的管理進步，使生產(chǎn)力諸要素的組合與運行達(dá)到合理優(yōu)化的狀態(tài)，不增加投入就可使現(xiàn)實生產(chǎn)力獲得盡可能大的提高，從而令管理收到事半功倍的效果。

　　海爾把PDCA運用到企業(yè)內(nèi)部的營銷隊伍管理上，那么，這種管理方法對外部營銷是否適用呢？

　　上海通用汽車公司成功地把此方法應(yīng)用于自己的經(jīng)銷體系中，極大地改善了經(jīng)銷商的服務(wù)。在其近100家經(jīng)銷商中，上海通用奉行的政策是，對一些業(yè)務(wù)表現(xiàn)不好、不能完成上海通用的要求、不能在市場上進行有效的開拓，或者在售后服務(wù)方面不能夠完全按照上海通用的理念和規(guī)范去操作的經(jīng)銷商，會先給他們做一個PDCA改進計劃。完成了這個計劃性的四部曲后，經(jīng)銷商的整個市場營銷的管理工作應(yīng)該會隨之步入一個良性循環(huán)的軌道。如果還是不行，經(jīng)銷商就會被淘汰掉。

　　由上可知，PDCA管理法的核心在于通過持續(xù)不斷的改進，使企業(yè)的各項事務(wù)在有效控制的狀態(tài)下向預(yù)定目標(biāo)發(fā)展。

　　先前的項目采用的是TyrexFactory作為事務(wù)工廠的實現(xiàn)，但是運行的過程中發(fā)現(xiàn)很不穩(wěn)定，處理大對象時容易出現(xiàn)事務(wù)超時的錯誤，即使事務(wù)設(shè)置的超時時間很長也是這樣，將jotm及其相關(guān)jar copy 到lib中之后，換成JotmFactory，發(fā)現(xiàn)TransactionFactory.getTransactionFactory竟然報NoSuchElementException。后來發(fā)現(xiàn)是carol.jar中的CarolConfiguration需要裝載jndi.properties文件進行初始化，而tyrex.jar自身有一個同名的文件，正是因為CoralConfiguration裝載了這個同名的文件才產(chǎn)生了異常，去掉tyrex.jar就可以了。

1. sleepTime：PoolKeeper檢測時間間隔
2. lifeTime：連接生命周期（上次訪問時間-當(dāng)前時間）
3. deadLockMaxWait(：超過最大連接之后的調(diào)用getConnection的等待時間
4. deadLockRetryWait：超過最大連接之后的調(diào)用getConnection等待，在等待中重試的時間間隔
5. maxSize：連接池的容量

deald-lock-max-wait和dead-lock-retry-wait的設(shè)置要小心，這兩個參數(shù)的意義見我的另一個日志：XAPool原理簡要分析。dead-lock-retry-wait最好設(shè)置得比較短，這樣不至于線程等待很長時間，dead-lock-max-wait的設(shè)置不要太長，一般是設(shè)置成比最高并發(fā)數(shù)下應(yīng)用處理時間稍長一點，設(shè)置過短在大并發(fā)下會造成提交實效導(dǎo)致應(yīng)用數(shù)據(jù)的丟失，因為超過xapool在超過等待dead-lock-max-wait之后會異常：沒有可用連接分配。

 

sleepTime是對Connection idle檢測線程PoolKeeper的檢測時間間隔設(shè)置。PoolKeeper會定時監(jiān)測是否存在超過lifeTime的connection然后釋放掉這些connection。不過PoolKeeper在運行的時候會檢查running屬性，以下是它的run方法中的代碼片斷：

之所以把這段代碼粘出來，是因為running屬性默認(rèn)是true，而GenericPool在啟動PookKeeper的時候并沒有改變這個值，因此PookKeeper永遠(yuǎn)不會運行起來。也許這是xapool的另一個bug：）

連接池的容量設(shè)置是有講究的，一般至少等于AppServer（或者叫WEB 容器）的最大并發(fā)數(shù)。因為xapool在達(dá)到maxSize的時候，如果還有線程需要連接，會進入等待狀態(tài)（通過deadLockMaxWait設(shè)置最大等待時間，deadLockRetryWait設(shè)置等待間隔），在大并發(fā)下會造成App Server容器線程池滿，Server在一段時間內(nèi)（deadLockMaxWait）停止響應(yīng)的現(xiàn)象。將連接池的容量設(shè)置成大于App Server的最大并發(fā)數(shù)，可以盡可能的避免這種情況。App Server的最大并發(fā)數(shù)=App Server的線程池線程數(shù)，Tomcat默認(rèn)是75，Websphere默認(rèn)是50。集群環(huán)境下，集群的最大并發(fā)數(shù)=每臺集群服務(wù)器的最大并發(fā)數(shù)之和