發(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：
封裝：
protected HttpServletRequest processMultipart(HttpServletRequest request) {
if (!"POST".equalsIgnoreCase(request.getMethod())) {
return (request);
}
String contentType = request.getContentType();
if ((contentType != null) &&
contentType.startsWith("multipart/form-data")) {
return (new MultipartRequestWrapper(request));
} else {
return (request);
}
}
還原：
在doForward和doInclude中在forward和include之前都執(zhí)行了下面的代碼：
if (request instanceof MultipartRequestWrapper) {
request = ((MultipartRequestWrapper) request).getRequest();
}
問題就出現(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中的配置文件多了一些地方：
<font name="Global" value="SansSerif,0,11" />
<font name="InternalFrame.titleFont" value="Trebuchet MS,1,11" />
<font name="TabbedPane.font" value="Tahoma,0,11" />
<font name="MenuBar.font" value="Tahoma,0,11" />
<font name="MenuItem.font" value="Tahoma,0,11" />
<font name="PopupMenu.font" value="Tahoma,0,11" />
<font name="Menu.font" value="Tahoma,0,11" />
把這些注釋掉，然后把配置文件放回到zip文件中就可以了。當(dāng)然你還可以嘗試采用其他的字體。
采用JGoodies的LookAndFeel出現(xiàn)亂碼，我曾經(jīng)以為是UTF-8的問題，現(xiàn)在看來可能也是字體導(dǎo)致的。可惜的是，JGoodies的LookAndFeel不能配置。
下午，試用了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中的這三個事件都作了如下的判斷：
public void mouseClicked(MouseEvent me) {
boolean popUpDisplayed = false;
if(me.isPopupTrigger() || me.getModifiers() == InputEvent.BUTTON3_MASK) {
popUpDisplayed = showPopup(me);
if (LOG.isDebugEnabled()) {
if (popUpDisplayed) LOG.debug("MousePressed detected as a popup and popup displayed and event consumed");
else LOG.debug("MousePressed detected as a popup but no popup to display");
}
return;
}
LOG.debug("MousePressed is not a popup trigger");
}
其中加紅的這段不知道為什么要作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)用。代碼示例：
Session session = openSession();
User user = (User)session.load(User.class,new Long(12));
user.setAddress(null);
session.update(user);
session.flush();
將hibernate配置成show_sql=true，可以看到update產(chǎn)生的sql語句。
2。不同session之間，update傳入的對象是另一個session中的persist對象（對該對象調(diào)用了create或者load方法）。代碼示例：
Session session1 = openSession();
User user = (User)session1.load(User.class,new Long(12));
Session session2 = openSession();
user.setAddress(null);
session2.merge(user);
session2.flush();
如果將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就可以了。
Ofbiz2.1有兩個bug，都涉及到線程安全性，小并發(fā)的時候不容易發(fā)現(xiàn)，大并發(fā)下有時候會出現(xiàn)，并發(fā)數(shù)越高出現(xiàn)的頻度就比較高，尤其對于實體引擎的那個bug，在系統(tǒng)初始化的時候如果遭遇大并發(fā)，會有一定頻度的出現(xiàn)。
1。entity engine的ModelEntity.getField方法存在線程安全隱患，會造成 XXXX is not a field of XXX的異常，以下是原有代碼片斷：
public ModelField getField(String fieldName) {
if (fieldName == null) return null;
if (fieldsMap == null) {
fieldsMap = new HashMap(fields.size());
for (int i = 0; i < fields.size(); i++) {
ModelField field = (ModelField) fields.get(i);
fieldsMap.put(field.name, field);
}
return (ModelField) fieldsMap.get(fieldName);
}
由于getField方法沒有同步（會造成性能下降），因此紅色標(biāo)標(biāo)注的那段代碼存在線程安全問題，必須進行同步。在大并發(fā)下如果多個調(diào)用這個方法，最先調(diào)用的線程沒有執(zhí)行完循環(huán)的情況下，后續(xù)的線程通過最后的語句return的時候得到的就是Null（fieldsMap已經(jīng)被第一個線程賦值了，后續(xù)線程不會進入紅色標(biāo)準(zhǔn)的代碼區(qū)域）。
修改后的代碼如下：
public ModelField getField(String fieldName) {
if (fieldName == null) return null;
if (fieldsMap == null) {
createFields();
}
return (ModelField) fieldsMap.get(fieldName);
}
public synchronized void createFields()
{
fieldsMap = new HashMap(fields.size());
for (int i = 0; i < fields.size(); i++) {
ModelField field = (ModelField) fields.get(i);
fieldsMap.put(field.name, field);
}
}
這個Bug在3.0中已經(jīng)被修正。
2。UtilCache.get方法同樣存在線程安全隱患，會造成LinkedList.remove或者LinedList.addFirst的空值針異常，不注意還會以為是LinkedList的bug。以下是原代碼片斷：
public Object get(Object key) {
if (key == null) {
missCount++;
return null;
}
UtilCache.CacheLine line = (UtilCache.CacheLine) cacheLineTable.get(key);
if (hasExpired(line)) {
// note that print.info in debug.properties cannot be checked through UtilProperties here, it would cause infinite recursion
// if (Debug.infoOn()) Debug.logInfo("Element has expired with key " + key);
remove(key);
line = null;
}
if (line == null) {
// if (Debug.infoOn()) Debug.logInfo("Element not found with key " + key);
missCount++;
return null;
}
// if (Debug.infoOn()) Debug.logInfo("Element found with key " + key);
hitCount++;
if (maxSize > 0) {
keyLRUList.remove(key);
keyLRUList.addFirst(key);
}
return line.getValue();
}
紅色標(biāo)準(zhǔn)的部分是有問題的代碼，修改后的代碼如下：
public Object get(Object key) {
if (key == null) {
missCount++;
return null;
}
UtilCache.CacheLine line = (UtilCache.CacheLine) cacheLineTable.get(key);
if (hasExpired(line)) {
// note that print.info in debug.properties cannot be checked through UtilProperties here, it would cause infinite recursion
// if (Debug.infoOn()) Debug.logInfo("Element has expired with key " + key);
remove(key);
line = null;
}
if (line == null) {
// if (Debug.infoOn()) Debug.logInfo("Element not found with key " + key);
missCount++;
return null;
}
// if (Debug.infoOn()) Debug.logInfo("Element found with key " + key);
hitCount++;
if (maxSize > 0) {
synchronized ( this)
{
keyLRUList.remove(key);
keyLRUList.addFirst(key);
}
}
return line.getValue();
}
這個BUG在3.0種也修正了。
1。XAPool是如何wrap jdbc driver返回的PreparedStatement的。
以下是StandardConnectionHandler中的checkPreparedCache代碼片斷
????synchronized?PreparedStatement?checkPreparedCache(
????????String?sql,
????????int?type,
????????int?concurrency)
????????throws?SQLException?{
????????log.debug(
????????????"StandardConnectionHandle:checkPreparedCache?sql='"?+?sql?+?"'");
????????PreparedStatement?ret?=?null;?//?the?return?value
????????//?NOTE?-?We?include?the?Connection?in?the?lookup?key.?This?has?no
????????//?effect?here?but?is?needed?by?StandardXAConnection?where?the?the?physical
????????//?Connection?used?can?vary?over?time?depending?on?the?global?transaction.
????????String?lookupKey?=?sql?+?type?+?concurrency;
????????//?used?to?lookup?statements
????????if?(preparedStatementCache?!=?null)?{
????????????Object?obj?=?preparedStatementCache.get(lookupKey);
????????????//?see?if?there's?a?PreparedStatement?already
????????????if?(obj?!=?null)?{?//?if?there?is
????????????????ret?=?(PreparedStatement)?obj;?//?use?as?return?value
????????????????try?{
????????????????????ret.clearParameters();?//?make?it?look?like?new
????????????????}?catch?(SQLException?e)?{
????????????????????//?Bad?statement,?so?we?have?to?create?a?new?one
????????????????????ret?=?createPreparedStatement(sql,?type,?concurrency);
????????????????}
????????????????preparedStatementCache.remove(lookupKey);
????????????????//?make?sure?it?cannot?be?re-used
????????????????inUse.put(lookupKey,?ret);
????????????????//?make?sure?it?gets?reused?by?later?delegates
????????????}?else?{?//?no?PreparedStatement?ready
????????????????ret?=?createPreparedStatement(sql,?type,?concurrency);
????????????????inUse.put(lookupKey,?ret);
????????????????//?will?get?saved?in?prepared?statement?cache
????????????}
????????}?else?{
????????????ret?=?createPreparedStatement(sql,?type,?concurrency);
????????}
????????//?We?don't?actually?give?the?application?a?real?PreparedStatement.?Instead
????????//?they?get?a?StandardPreparedStatement?that?delegates?everything?except
????????//?PreparedStatement.close();
????????ret?=?new?StandardPreparedStatement(this,?ret,?lookupKey);
????????return?ret;
????}
2。StandardPreparedStatement的Close方法代碼片斷
????public?void?close()?throws?SQLException?{
????????//?Note?no?check?for?already?closed?-?some?servers?make?mistakes
????????closed?=?true;
????????if?(con.preparedStmtCacheSize?==?0)?{
????????????//?no?cache,?so?we?just?close
????????????if?(ps?!=?null)?{
????????????????ps.close();
????????????}
????????}?else?{
????????????con.returnToCache(key);
????????????//?return?the?underlying?statement?to?the?cache
????????}
????}
3。xapool StandardPoolDataSource的getConnection 原理：
??
?? StandardPoolDataSource.getConnection --> GenericPool.checkOut-->StandardPoolDataSource.create -->StandardPoolDataSource.getPooledConnection：返回StandardPooledConnection。?
???? StandardPooledConnection通過StandardDataSource.getConnection獲取jdbc driver返回的connection（physical connection），然后通過工廠方法newConnectionHandle采用StandardConnectionHandler對該connection進行包裝。StandardConnectionHandler對PreparedStatement進行重新包裝和Cache，對connection.close進行了控制。
?
4。xapool StandardXAPoolDataSource的getConnection的原理：
?? StandardXAPoolDataSource.getConnection -->StandardPoolDataSource.getConnection-->StandardXAPoolDataSource.create -->XADataSource.getXAConnection -->StandardXADatasource.getXAConnection：返回StandardXAConnection。
??? StandardXAConnection通過StandardDataSource.getConnection獲取jdbc driver返回的connection（physical connection），然后通過工廠方法newConnectionHandle采用StandardXAConnectionHandle對該connection進行包裝。StandardXAConnectionHandler繼承自StandardConnectionHandler。
?
5。xapool從StandardPoolDataSource獲取的 Connection的關(guān)閉原理。
?? StandardPooledConnection.close-->StandardConnectionHandler.close（設(shè)置closed=true，回收PreparedStatement）-->StandardPooledConnection.closeEvent-->StandardPoolDataSource.connectionClosed-->GenericPool.checkIn（返回連接池）
?
6.xapool中對連接池進行管理的類是GenericPool，該類的checkOut和checkIn方法分別完成連接獲取和連接回收功能。checkOut從unlocked池中獲取可用的連接，如果需要進行檢查或者測試，然后返回；如果發(fā)現(xiàn)unlocked池中沒有連接，在連接數(shù)小于maxSize的時候調(diào)用PoolHelper的實現(xiàn)類創(chuàng)建連接，如果連接數(shù)已經(jīng)達(dá)到或者超過maxSize，調(diào)用wait使當(dāng)前進程進入等待狀態(tài)（等待期限和等待間隔可以設(shè)置），如果等待過程中其他線程釋放了connection返回可用的connection，否則異常：GenericPool:checkOut ERROR? impossible to obtain a new object from the pool
- sleepTime：PoolKeeper檢測時間間隔
- lifeTime：連接生命周期（上次訪問時間-當(dāng)前時間）
- deadLockMaxWait(：超過最大連接之后的調(diào)用getConnection的等待時間
- deadLockRetryWait：超過最大連接之后的調(diào)用getConnection等待，在等待中重試的時間間隔
- 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方法中的代碼片斷：
while (! running && !Thread.interrupted()) {
System.err.println("!!!!"+System.currentTimeMillis());
try {
synchronized (this) {
wait(this.sleepTime); // wait for timeout ms before attack
}
} catch (InterruptedException e) {
break;
}
this.pool.cleanUp(); // clean up the Pool and reallocate objects
}
// release the pool.
this.pool = null;
之所以把這段代碼粘出來，是因為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ù)之和
現(xiàn)狀：我們的項目中使用了ofbiz2.1，并采用JotmFactory作為TransactionFactory，使用Oracle9i數(shù)據(jù)庫，在大并發(fā)測試的時候發(fā)現(xiàn)數(shù)據(jù)庫游標(biāo)暴漲并且不釋放，最終導(dǎo)致游標(biāo)溢出。
原因分析：ofbiz entityengine的很多操作都是使用PreparedStatement完成的，這無可厚非，問題是JotmFactory采用的是XAPool作為連接池，而XAPool對PreparedStatement進行了Cache，同時Oracle有一個出名的內(nèi)存漏洞，PreparedStatement使用之后必須關(guān)閉，如果不關(guān)閉連續(xù)進行SQL查詢會造成前面SQL的游標(biāo)不能釋放；此外JotmConnectionFactory沒有允許對XAPool做更多的配置，按照它使用XAPool的方式，XAPool會對PreparedStatement進行Cache。Oracle漏洞+ofbiz的不周全的使用方式+xapool的機制造成了游標(biāo)不釋放最終溢出的異常。
解決辦法：修改JotmConnectionFactory，調(diào)用StandardXAPoolDataSource的setPreparedStmtCacheSize(int)的方法，將preparedStmtCacheSize設(shè)置為0。需要注意的是xapool在目前的版本（1.4）當(dāng)preparedStmtCacheSize=0的時候存在一個bug，close PreparedStatement的時候會報NullPointerException，請參考我的另一個日志
XAPool1.4的bug。
現(xiàn)狀：XAPool1.4有一個bug，當(dāng)設(shè)置preparedStmtCacheSize=0的時候，關(guān)閉連接會拋出NullPointerException
原因：StandardConnectionHandle在Close的時候調(diào)用了preparedStatementCache.cleanupAll()，沒有進行判斷；而當(dāng)preparedStmtCacheSize設(shè)置為0的時候，StandardConnectionHandle在setupPreparedStatementCache中把preparedStatementCache設(shè)置為null，以下setupPreparedStatementCache是方法中的源代碼片斷：
protected void setupPreparedStatementCache() {
log.debug("StandardConnectionHandle:setupPreparedStatementCache start");
if (preparedStmtCacheSize == 0) {
log.debug(
"StandardConnectionHandle:setupPreparedStatementCache return with 0");
preparedStatementCache = null;
return;
}
解決辦法：修改setupPreparedStatementCache，如下：
if (preparedStmtCacheSize == 0) {
log.debug(
"StandardConnectionHandle:setupPreparedStatementCache return with 0");
// preparedStatementCache = null;
preparedStatementCache = new PreparedStatementCache(0);
return;
}
現(xiàn)狀：在我們的項目中使用了Ofbiz2.1，TransactionFactory配置為JotmFactory，數(shù)據(jù)庫是Oracle9i，lifeTime設(shè)置為120000（2分鐘）在大并發(fā)測試的時候發(fā)現(xiàn)經(jīng)常Closed Connection的異常。
原因：Oracle數(shù)據(jù)庫會檢查physical connection的idle時間和使用次數(shù)并關(guān)閉長時間idle的physical connection，如果應(yīng)用對從連接池中
獲取的connection不進行檢查，或者連接池仔返回可用連接之前不進行檢查，在使用過程中就會Closed Connection的異常。大多數(shù)數(shù)據(jù)庫都會檢查physical connection的idle時間。
解決辦法：調(diào)用StandardPoolDataSource或者StandardXAPoolDataSource的setCheckLevelObject(int)方法設(shè)置連接檢查級別，參數(shù)取值如下：
-
0:不檢查
-
1:對unlocked池中獲取的連接進行Closed檢查
-
2:對unlocked池中獲取的連接進行sql測試，需要設(shè)置setJdbcTestStmt(Test SQL)
-
3:對所有unlocked池中的連接進行Closed檢查
-
4:對所有unloked池中的連接進行測試，需要設(shè)置setJdbcTestStmt(Test SQL)
打算將我在http://jdev.blogdriver.com 的blog搬過來。