Goingmm

祝大家節日快樂!

結束了9月繁忙的工作.回家休息了

很長時間沒上來更新. 生活比較瑣碎 .

TrackBack:http://www.tkk7.com/goingmm/archive/2006/06/23/54595.html

朋友們 五一快樂
出游的朋友注意安全
呆家里的朋友不要光顧著睡覺
平時很少有機會看太陽哦

我呢？
回家 事實基本上已經不允許了
出游 一直想去新加坡看看老朋友
發現新加坡的單程機票200多[廣州白云機場→新加坡]
可惜等我知道的時候三個月內的都預定空了
再等下一次大假吧

忙碌了幾個月
我也說不清楚做了些啥
但總算還是有一些小收獲

有些煩人的問題...
現在終于有時間好好補補了
正好有時間總結 總結

下一次上來 一定把這三個月忙碌的過程和結果與大伙分享

Goingmm 2006-05-01

忙了一個星期，事情總算平穩的起步了
該睡覺了

睡醒了再說...

2006-03-19? Goingmm

這些天雜亂的事情太多
要呆到20：00才回家
不是給公司加班
可能是為自己奇異的想法

昨天晚上
在王府井外面聽到一首歌
當時
只記得一句歌詞：“想起我和你牽手的畫面”

早上過來，歌詞幾乎都忘了
嘗試搜索，居然找到了

我不知道[想起]是新歌還是老歌
感覺有點懷舊，又有點抄襲
曲調能讓我想起十年前[蔡琴她們那些時代]
部分節奏有點抄襲“神話主題曲”

推薦給大伙 聽聽看吧

曲名：想起 歌手：韓雪  
 
回到相約的地點
在這我對你不了解
以為愛得深就不怕傷悲
偏偏愛人心成雪
我獨自走在寂寞的長街
回憶一幕幕重演
我告訴自己勇敢去面對
就算心碎也完美
想起我和你牽手的畫面
淚水化成云霞滿天
如果我和你還能再見面
就讓情意舊夢能圓
我們在不同的世界
想著每一次的誤會
好像再一次依偎你身邊
偏偏你有千里遠
我獨自走在寂寞的長街
回憶一幕幕重演
我告訴自己勇敢去面對
就算心碎也完美
想起我和你牽手的畫面
淚水化成云霞滿天
如果我和你還能再見面
就讓情意舊夢能圓 

Goingmm 2006-03-10
 

請看：
http://www.igoogle8.com/igoogle8/make/?f=1&s=Goingmm&t=0
很奇怪吧？google怎么變成連版權都“個性化”的主頁了。而且用起來和google感覺還一模一樣

再看：
http://www.igoogle8.com/

原來：
http://www.igoogle8.com/ 做了手腳

接著：
主頁上沒有作者或者運營商的任何信息，于是打開google查詢關鍵字“igoogle8”
http://www.google.com/search?hl=zh-CN&q=igoogle8&btnG=Google+%E6%90%9C%E7%B4%A2&lr=lang_zh-CN%7Clang_zh-TW

哇！69 項符合igoogle8的查詢結果 大致看了一下
Google狗年悄悄發布新品“愛狗狗吧”，引來網民蜂擁測試- 雅虎論壇
iGoogle8愛狗狗吧/ 一秒鐘將Google據為己有 - 4:12
iGoogle8愛狗狗吧，將Google據為己有/ 向好友推薦iGoogle8愛狗狗吧
iGoogle8愛狗狗吧/ 超級女聲·狗狗爬行榜
。。。。。。。。。。。。。。。。。。。。。。。。。

后來：問了問GoogleChina 的朋友。他們也不知道這玩意

作者弄了這么一個東西，但是又不做宣傳。居然還有人猜測是Google中國出的產品
其他不說，就看主頁下面的[向好友推薦igoogle8 和 設為主頁] 這也不可能是google所為啊

于是：查了查igoogle8的服務環境

OS	Server	Last changed	IP address	Netblock Owner
FreeBSD	Apache	8-Mar-2006	59.151.5.206	Abitcool(China) Inc.

1	forex.com.cn	3	10	3	Windows Server 2003	Microsoft-IIS/6.0
2	e4u.cn	-	41	41	Linux	Apache-Coyote/1.1
3	qunar.com	-	-	-	Linux	Apache
4	www.zhanzuo.com	-	25	25	FreeBSD	Apache/1.3.34 (Unix) PHP/4.4.2
5	www.igoogle8.com	-	-	-	FreeBSD	Apache

結論：這家伙 不可能和Google有什么關系

Goingmm 2006-03-08

    Blog左邊新加了一個LOGO  點擊 可以立刻和我的QQ建立臨時通話通道
    
    旁邊還有一個小企鵝圖標。如果亮著就表示在線 灰著就表示隱身  呵呵！

    如果我的QQ不在線 你也可以留言給我。 我測試過，能收到歷史消息 
    
    空了 多做幾個LOGO輪換著用

    Goingmm 2006-03-04

     Key Words: Sun Microsystems   Java SE 6 Beta

     歷時一年時間，Sun 終于推出了Java SE 6 Beta。這是Java SE 6（Mustang）的第一個完整版本。其中的亮點包括，web services，新的安全機制和管理，改進的desktop用戶體驗，File類添加了一些檢查磁盤空間的API。Splash Screen 等等
      當然還有 Fixed and Known Bugs

Downloading url:http://java.sun.com/javase/6/download.jsp

Goingmm  2006-02-16  from:csdn



     Goingmm 2006-02-17   Modified

 新聞：2006年2月14日，Google中國黑板報[www.googlechinablog.com] 正式開通

 定位：普通Google員工與網民分享交流產品、技術和文化的窗口
 布局：左邊[2/3]用Blog做噱頭[ 吸引眼球]  +  右邊[1/3][ 推銷自己的產品鏈接Google忠實的網絡推手]
 用意：眼看中國這么大的市場，Google也急于在中國本地化，用心良苦
 花絮：圖片“Google 中國工程師在工作”有一個胖娃的背影，有點像老“XU”
 視角：直白的商業運作模式，不一定能拿到Google員工直白的心聲。喜歡關注Google的朋友，可以期待和觀望
              企業比較低廉的一種公關模式。期待交流的想法是無庸置疑的，值得表揚

Goingmm 2006-02-15

注意看紅色圈住的人是誰？ 老XU 啊！~~ 點圖片有超鏈


Goingmm 2006-02-17 修改

    

Key words
Name:     Apache Tomcat Version 5.5.9                                            
Release:  v 1.25 2005/01/19 20:30:26
JDK:        1.4.2 OR 5.0

背景：
    JDK5.0 + Tomcat 5.5.9
    去年，因為嘗鮮一直使用JDK5.0。使用這個搭配也從來沒有遇到問題

    JDK1.4.2 + Tomcat 5.5.9
    今年拿到新電腦后，現在的開發環境很依賴環境變量的設置。出于謹慎我還是選擇了使用JDK1.4.2
    昨天晚上無聊的裝上Tomcat 5.5.9玩
    
    1）JRE選擇JDK1.4.2 安裝完成
    2）用Monitor Tomcat 啟動Tomcat
    3）打開http://127.0.0.1:8080/
    4）找不到服務器
    5）感覺+漫罵... 真他NND的奇怪了 疑惑什么地方弄錯了

改裝經歷：
    咱，不能丟臉的被這只貓貓忽悠吧！
    于是，很不耐煩的找出這個版本的RELEASE-NOTES（壞習慣-不太喜歡看說明）

   ==================
    Dependency Changes:
    ==================
    Tomcat 5.5 is designed to run on J2SE 5.0 and later, and requires
    configuration to run on J2SE 1.4.  Make sure to read the "RUNNING.txt" 
    file in this directory if you are using J2SE 1.4.

    In addition, Tomcat 5.5 uses the Eclipse JDT Java compiler for compiling
    JSP pages.  This means you no longer need to have the complete
    Java Development Kit (JDK) to run Tomcat, but a Java Runtime Environment
    (JRE) is sufficient.  The Eclipse JDT Java compiler is bundled with the 
    binary Tomcat distributions.  Tomcat can also be configured to use the
    compiler from the JDK to compile JSPs, or any other Java compiler supported 
    by Apache Ant.
    
     Installing the compatibility package will add the following to the list, which are
     needed when running on J2SE 1.4:
     * jmx.jar (Java Management Extensions API 1.2 or later)
     * xercesImpl.jar (Xerces XML Parser, version 2.6.2 or later)

     呵呵... 這里解釋的很清楚
     ? Tomcat 5.5 只默認支持J2SE 5.0 and later
     ? Tomcat 5.5  在編譯JSP上做出的改變
    
     但是,TNND后面一段關于在JDK1.4上配置運行的描述,實在是太迷糊人了[根本沒有說清楚]
     根據他表達的意思我試過很多方法
     ? 看來想要“不妥協”的使用，唯有“改裝”。有了改裝的初步想法
     ? 在我的機器里面找看有沒有現成的jar包 發現了幾個相似的包 測試不行
     ? 到官方網站[http://tomcat.apache.org/download-55.cgi]把所有的包都down下來看
     ? 最后發現一個像摸像樣的包[apache-tomcat-5.5.15-compat]但是和我現在的Tomcat版本不一樣
     ? 抱著試一下的心態。解壓縮出來兩個文件夾 ① bin ②common 用他們覆蓋安裝目錄下的文件夾
     ? 用Monitor Tomcat 啟動Tomcat
     ? 打開http://127.0.0.1:8080/ 看到了熟悉的貓貓 
     ? Bingo，記錄下這次“改裝”的經歷

經驗總結：
      其實，這只是我們平時遇到的很小很小的問題（菜鳥問題）
      問：為什么要總結呢？為什么還用小題大作寫成blog呢？
      結：使用任何產品，用心看看說明文檔 是非常有必要的。尊重產品工作者的勞動，
               自己也能少很多麻煩
     
順便... 鏈接其他：
      關于Tomcat各個版本的運行速度。emu 哥哥在他最近的blog中給出了測試結果
      個人感覺
      ?  Tomcat 越新的版本使用越方便[基本上不需要單獨配置]
      ?  Tomcat 不為我們熟悉的功能也越來越多[平時沒用到的也沒去關注過]
      ?  Tomcat  運行速度的測試結果，我還是比較疑惑

   Goingmm  2006-02-12

  ? 280公里意味著什么？

             高速公路2.5小時車程，火車3.5小時行程

     ? 280公里發生了什么？

             兩次/年 片刻停泊 留下的唯有牽掛

     ? 280公里給了我什么？

             時間換來單薄生存 享受的唯有牽掛

     初八是個好日子 書上說：“七不出門，八不歸家”

     又要出發了 離家的感覺是牽掛

     爸媽牽掛280公里外的我 平平安安 有獲

     我牽掛280公里外的父母 身體健康 發財

     南充 [ 一個“變化”很大的城市 ]

     說“浮華”不敢  我不敢靠“淺嘗”的數字來誹謗

     說“作踐”不愿  我不愿靠“批露”的聲音來出名

     說“獨特”不能  我不能靠“斷言”的措辭來浮夸

     說“自清”不想  我不想靠“忘根”的情愫開解脫

     原本以為，可以把這里的“精彩”和大家分享

     調皮的光標‘怪異’的擺下這個‘怪異’的標題

     我能想到的，只有明天280公里遠去的牽掛

     送給

     每一個即將離開父母去找尋夢想的朋友

     或許，你們的牽掛是2800公里 28000公里…

     臨走時，別忘了

     用心摸摸爸爸的皺紋

     悄悄數數媽媽的白發

     Goingmm Subscription  2006-2-5 凌晨

凌晨，看到一個挺有趣的討論[JavaEye]。2006年，Java界的主題將是什么？

兩年的開發經歷，對新技術的追逐與否我不敢妄自評論。茶余飯后無聊的思考
基礎顯然重要，當新事物能為我所用的時候，能快速應對，足以
不可否認，新技術的出現,往往能成就一批熱心追逐的人[只是少部分，大部分屬于隨波逐流的困惑]

2000年 應用服務器年 
       這一年，Java應用服務器的需求成為各大公司的最大利益。誰不希望用“業界標準”來標榜自己呢！
■  BEA公司的繁榮從此開始

2001年 EJB年
       這一年，EJB2.0發布，整個Java業界為之震動，“牽強”的分布式架構，讓EJB成了魔術詞匯
■  EJB成了高價企業軟件的“文憑”。懂不懂EJB成為能不能拿到高薪的關鍵

2002年 設計模式年
       這一年，大家開始發現EJB真TNND難用，開始發現Java開發需要遵循某種規則，設計模式開始流行，
       J2EE核心模式也應運而生
■   jdon網站借著設計模式的熱點一舉成名

2003年 Hibernate年
       這一年，大家開始否定EJB，開始采用O/R Mapping，Hibernate迅速流行
■  JavaEye由于頗有預見性的推廣普及Hibernate而成為國內Java社區的亮點

2004年 Spring年 
       這一年,EJB3規范和JDO2規范忙著打架，但是真正的主角是Spring，Spring攜著IoC和AOP迅速占領J2EE的眼球.
■  《Without EJB》 成為大家背棄EJB2.0的宣言書

2005年 AJAX年
       這一年，大部分時間大家都在反思，或者是學習合適的應用程序架構。伴隨著Google的Gmail，
       Google Maps等一系列AJAX應用，一個古老的XMLHTTP組件咸魚翻身。這個冬天終于找到了主題-AJAX
■  驕傲的程序員回頭關注“用戶體驗”

2006年 XX年？
       這一年，除了成名已久的EJB3.0值得期待，我們還能看到出人意料的新名詞嗎？
       這一年，將會是更深刻的反思年嗎？[用已有的技術集合更完美的“用戶體驗”]
       這一年，我們將何去何從，我也說不清楚
       你呢？

 Goingmm  2006-02-03

    2006年1月25日早上9點起床
    收拾了幾件換洗的衣服準備回家
    回家的心情是急切的，關上門
    剛走出幾步
    又摸出鑰匙串 回去掃視著整個房間
   
    是不舍？
    是不情愿？
    是不放心？

    好像感覺有什么東西落下了
    似乎惦念著還有什么事沒有做完
   
    5分鐘后沒有任何發現 倔強的離開了
    在離開的的士上還在猜疑
    永遠離別一個城市也不曾有過的感覺
   
    大年三十
    陪爸爸媽媽看完春節晚會
    邀集一伙朋友準備出去“通宵”
    因為今年是本命年
    大伙都建議上廟去求個 [ 2006 平安 ]
   
   坐車+走路 1小時就到了
   見了 如來佛 觀音菩薩 十八羅漢 財神爺 ...
   祈禱的心是誠實的
   面對恩賜，永不滿足的心 感覺太亂

   大年初二
   一伙朋友坐船出去 游嘉陵江
   目的地是 
   50多年前“毛主席的共產主義作品” -- 農村合作社
   看著 破陋的 兩排男女宿舍+兩間夫妻房
    聽著  89歲老人淳樸的歌聲“社會主義好”
    喝著 所謂的“大鍋飯”（一大鍋紅薯稀飯）
    
    50  年前的“共產主義”    
    500年后的“共產主義”
    
    希望 至少能像廟里的菩薩
    給我一點虔誠的勇氣 

    心突然...
   
    Goingmm  2006-01-30
     
   

BLOGJAVA 服務器居然是這個配置

Windows Server 2003

Microsoft-IIS/6.0

15-Jan-2006

61.147.119.205

CHINANET jiangsu province yangzhou city network

   2006-1-1 15：30 打開眼睛，撕開被子，立起枕頭，挺冷的，想躺下繼續睡。 
   2006是我的本命年，迷信嗎？還有點心虛。理性吧！有準備承受更大的壓力。

   新年的第一天，你是怎么過的？有為自己在新的一年做計劃嗎？有和朋友一起出去大吃一頓慶祝嗎？有像我一樣睡昏了頭的嗎？看看我新年第一天的流水帳吧！
   什么都還沒有做，心里有點怪怪的。為什么會有點發了慌的感覺。因為什么都沒有做發慌嗎？可能是肚子太餓了。 
   找到一家象樣的中餐館子。要了一盤“鍋盔回鍋”，還特意叫老板上了一碟紅油泡菜。整碗白米干飯。很不錯哦。
   吃飽回家看會電視（湖南電視臺的新春晚會），TNND翻來覆去都是那幾個“超女”沒看頭。
   點支煙，摸出電腦準備聽會音樂，翻翻過去一年的照片。讓回憶在“小資”中升華。突然記起前幾天Down了WTP1.0。最近在翻看一些經典電影。一直都沒時間玩玩。于是打開玩，等我再次感覺肚子餓已經是晚上22：20
   對了，MIKE明天就要去SOHU了。臨別前，給他電話送別。那娃居然在打麻將。不曉得聽懂我送別的良苦用心沒有。愿他一路順風。新年新成績吧！
   放下電話，煮碗面吃，又看見昨天泡的衣服都還沒有洗。
   洗衣服是一件很有趣的事情。平時很少有機會運動，這時候可以湊合著活動一下。平時繃緊的神經挺累的。這時候，可以很享受的哼唱著散碎的歌曲。憂郁了，可以試著在發泄中思考。享受著局外人的寧靜
   工作快兩年了，自己問過自己一個問題，說忙也好，頹廢也吧。一直在回避，怕自己知道答案后會后悔當初。會逃避現實生活，會不知所措…偏偏在這時候想起“為什么想要做一個程序員”。
   當初可能有一種不服輸的想法。計算機畢業總能混碗吃吧。靠自己的雙手生存的感覺真的不錯。但是這種感覺很短暫。
   晚上的公交車窗外，燈紅酒綠。而我們只屬于浮華背后的看客。躲在車窗后面的我們，窺視著，YY著。或許有著無數的感慨和暢想。或許回味著有時候也加入其中。哽咽著洗腳水味的洋酒。帶著酒意，舞動在模糊迷人的身體背后。那是在發泄，那是在饑渴的釋放… 那是一只披著羊皮的狼。
   因為…這里沒有欺騙，沒有勾心斗角，沒有討價還價，很單純，單純到你可以沒有其他的任何生活方式。在這里你可以找到攻城拔寨的快感。可以享受與世隔絕的寧靜。懷揣骨子里面的清高。或許還能享受在別人眼中的高手身份吧！
   大多數程序員都會經歷 新手學習；逐漸成熟；自暴自棄，浮躁得異想天開；走向成熟或者是不知天高地厚得狂妄。
   很難定義自己現在所處的階段。就算在浮躁期吧。有了一點小小的成就感以后，就會變的浮躁，開始去思考，為什么做程序員，現在該拿多少薪水，夢想的實物該拿什么去換…
      我不敢奢望誰能去幫我承擔這種浮躁…光標閃到這里，變得機械了。突然沒言語
   知道自己需要有一段長時間的休息。去忘掉Source Code，淡化網絡給我們帶來的便捷。開始打算著，選擇離開一段時間。離開Office，離開友情深深的團隊。離開這塊“凈土”去瞧瞧陌生的精彩。回到闊別已久的老家追憶童年。或許生活的不堪重負會讓我減卻浮躁。或許該把競技的舞臺留給更多饑渴的勇士。這樣對大家都好。

   都說，新的一年應該給自己一個新的計劃。計劃如果有Scope的話。可以把他分成三種

n    Request 類型的 [每一次記得了，看看計劃，傻笑一下，干一次]

n    Session 類型的 [在一個階段給自己的計劃，可以按計劃堅持干完]

n    持久    類型的 [給自己一個長期的計劃，不懈的努力]

面對計劃，我就屬于第一種，哈哈！給大家說一段笑話吧。大學的時候計劃考英語四級，買了本單詞來背。前些天再次想起，翻出來看的時候發現結果才看到“E”。看了兩天又丟一邊了。

所以，有時候我不太喜歡過場式的給自己計劃。做好每一天，讓“鮮為人知的理想”離我越來越近就好。今天打算為浮躁埋單

    衣服洗完了，好象今天洗得特別干凈。新年新氣象嘛！


Goingmm Subscription 2006-01-01

      
       WTP（Web Tools Platform）是Eclipse組織的一個針對J2EE做的一個開發工具插件，是Eclipse下面的一個項目.使用過WTP 0.7的用戶都知道，WTP提供了幾乎完整的Web應用開發的工具支持.
      12月19日，Eclipse基金會發布了WTP(Web Tool Project) 1.0rc版本.當天只發布了相關的插件包。我大概是25號從官方網站http://download.eclipse.org/webtools/downloads/drops/R-1.0-200512210855/拿到了全集成的版本（Eclipse Version: 3.1.1 Build id: M20050929-0840）。
     用這個版本寫了一個DEMO。感覺是上手挺容易的。V1.0在V0.7的基礎上Fixed了一些Bug。而且有些功能點簡化了。做得更common一些。使用過程遇到一些問題，但我不肯定是不是對環境不夠熟悉造成的誤解。比如修改一個JSP的名字，怎么發布都報錯，只有關掉WTP重新Init一次。還有中文問題在這個環境中仍然存在。為了不寫Action和相關配置文件，我用一個Servlet來控制轉發的，加上一句req.setCharacterEncoding("gb2312")就搞定了。

    列舉主要使用過程：
    ■ Setup and configuration 
    ■ Development basics       
    ■ JSP Editing                     
    ■  Servlets                         
    ■  Deployment descriptors  
    ■  Structure Source Editing (SSE) framework
    ■  Server
    ■  Running and debugging the web app

     準備放這個Demo的過程,和簡單的代碼。但是篇幅原因，我就只能放一些零碎的圖片。在這里沒有打算告訴大家怎么去寫一個簡單的Web應用。如果對WTP感興趣的話，這里就當是一些初級的了解吧。有什么問題歡迎討論。
      
      WTP的基礎了解 PIC
     

    

    基本配置 PIC
   

   

   關于DEMO PIC
  

  添加一個這樣的服務器很簡單。和WSAD差不多

啟動好的服務器


運行JSP


登陸頁面




登陸成功


中文請求 演示





END


goingmm 2006-01-02

異常處理

       曾經專門花時間研究過JAVA中“異常處理”。一直想寫一篇文章。也一直沒有找到合適的方式。概念書上都有，在這里我再重提又覺得對不起大家。最后就不了了之。
       無意間，看到CSDN上有一篇文章寫得不錯。轉給大家看看吧。作者給出了很標準的做法，這里我加點建議。
      
       僅供參考 注：所有建議都不會去懷疑和針對，作者想要講解的異常處理知識點
     ￠ Source code的每一個角落都這樣100%標準的去處理異常。會一定程度的影響代碼質量。不要相同的處理邏輯反復出現（比如用Template模式簡化處理過程）         
  ￠ 根據自己的實際情況選擇異常使用，能不用異常處理的時候盡量不要用。有時候沒有必要“強求”100%       
      
      轉貼內容

      你覺得自己是一個Java專家嗎？是否肯定自己已經全面掌握了Java的異常處理機制？在下面這段代碼中，你能夠迅速找出異常處理的六個問題嗎？
    

 11 OutputStreamWriter out =  
 22 java.sql.Connection conn =  
 33 try { // ⑸ 
 44 　Statement stat = conn.createStatement(); 
 55 　ResultSet rs = stat.executeQuery( 
 66 　　"select uid, name from user"); 
 77 　while (rs.next()) 
 88 　{ 
 99 　　out.println("ID：" + rs.getString("uid") // ⑹ 
1010 　　　"，姓名：" + rs.getString("name")); 
1111 　} 
1212 　conn.close(); // ⑶ 
1313 　out.close(); 
1414 } 
1515 catch(Exception ex) // ⑵ 
1616 { 
1717 　ex.printStackTrace(); //⑴，⑷ 
1818 }

作為一個Java程序員，你至少應該能夠找出兩個問題。但是，如果你不能找出全部六個問題，請繼續閱讀本文。

　　本文討論的不是Java異常處理的一般性原則，因為這些原則已經被大多數人熟知。我們要做的是分析各種可稱為“反例”（anti-pattern）的違背優秀編碼規范的常見壞習慣，幫助讀者熟悉這些典型的反面例子，從而能夠在實際工作中敏銳地察覺和避免這些問題。

　　反例之一：丟棄異常

　　代碼：15行-18行。

　　這段代碼捕獲了異常卻不作任何處理，可以算得上Java編程中的殺手。從問題出現的頻繁程度和禍害程度來看，它也許可以和C/C++程序的一個惡名遠播的問題相提并論??不檢查緩沖區是否已滿。如果你看到了這種丟棄（而不是拋出）異常的情況，可以百分之九十九地肯定代碼存在問題（在極少數情況下，這段代碼有存在的理由，但最好加上完整的注釋，以免引起別人誤解）。

　　這段代碼的錯誤在于，異常（幾乎）總是意味著某些事情不對勁了，或者說至少發生了某些不尋常的事情，我們不應該對程序發出的求救信號保持沉默和無動于衷。調用一下printStackTrace算不上“處理異常”。不錯，調用printStackTrace對調試程序有幫助，但程序調試階段結束之后，printStackTrace就不應再在異常處理模塊中擔負主要責任了。

　　丟棄異常的情形非常普遍。打開JDK的ThreadDeath類的文檔，可以看到下面這段說明：“特別地，雖然出現ThreadDeath是一種‘正常的情形’，但ThreadDeath類是Error而不是Exception的子類，因為許多應用會捕獲所有的Exception然后丟棄它不再理睬。”這段話的意思是，雖然ThreadDeath代表的是一種普通的問題，但鑒于許多應用會試圖捕獲所有異常然后不予以適當的處理，所以JDK把ThreadDeath定義成了Error的子類，因為Error類代表的是一般的應用不應該去捕獲的嚴重問題。可見，丟棄異常這一壞習慣是如此常見，它甚至已經影響到了Java本身的設計。

　　那么，應該怎樣改正呢？主要有四個選擇：

　　1、處理異常。針對該異常采取一些行動，例如修正問題、提醒某個人或進行其他一些處理，要根據具體的情形確定應該采取的動作。再次說明，調用printStackTrace算不上已經“處理好了異常”。

　　2、重新拋出異常。處理異常的代碼在分析異常之后，認為自己不能處理它，重新拋出異常也不失為一種選擇。

　　3、把該異常轉換成另一種異常。大多數情況下，這是指把一個低級的異常轉換成應用級的異常（其含義更容易被用戶了解的異常）。

　　4、不要捕獲異常。

　　結論一：既然捕獲了異常，就要對它進行適當的處理。不要捕獲異常之后又把它丟棄，不予理睬。

　　反例之二：不指定具體的異常

　　代碼：15行。

　　許多時候人們會被這樣一種“美妙的”想法吸引：用一個catch語句捕獲所有的異常。最常見的情形就是使用catch(Exception ex)語句。但實際上，在絕大多數情況下，這種做法不值得提倡。為什么呢？

　　要理解其原因，我們必須回顧一下catch語句的用途。catch語句表示我們預期會出現某種異常，而且希望能夠處理該異常。異常類的作用就是告訴Java編譯器我們想要處理的是哪一種異常。由于絕大多數異常都直接或間接從java.lang.Exception派生，catch(Exception ex)就相當于說我們想要處理幾乎所有的異常。

　　再來看看前面的代碼例子。我們真正想要捕獲的異常是什么呢？最明顯的一個是SQLException，這是JDBC操作中常見的異常。另一個可能的異常是IOException，因為它要操作OutputStreamWriter。顯然，在同一個catch塊中處理這兩種截然不同的異常是不合適的。如果用兩個catch塊分別捕獲SQLException和IOException就要好多了。這就是說，catch語句應當盡量指定具體的異常類型，而不應該指定涵蓋范圍太廣的Exception類。

　　另一方面，除了這兩個特定的異常，還有其他許多異常也可能出現。例如，如果由于某種原因，executeQuery返回了null，該怎么辦？答案是讓它們繼續拋出，即不必捕獲也不必處理。實際上，我們不能也不應該去捕獲可能出現的所有異常，程序的其他地方還有捕獲異常的機會??直至最后由JVM處理。

　　結論二：在catch語句中盡可能指定具體的異常類型，必要時使用多個catch。不要試圖處理所有可能出現的異常。

　　反例之三：占用資源不釋放

　　代碼：3行-14行。

　　異常改變了程序正常的執行流程。這個道理雖然簡單，卻常常被人們忽視。如果程序用到了文件、Socket、JDBC連接之類的資源，即使遇到了異常，也要正確釋放占用的資源。為此，Java提供了一個簡化這類操作的關鍵詞finally。

　　finally是樣好東西：不管是否出現了異常，Finally保證在try/catch/finally塊結束之前，執行清理任務的代碼總是有機會執行。遺憾的是有些人卻不習慣使用finally。

　　當然，編寫finally塊應當多加小心，特別是要注意在finally塊之內拋出的異常??這是執行清理任務的最后機會，盡量不要再有難以處理的錯誤。

　　結論三：保證所有資源都被正確釋放。充分運用finally關鍵詞。

反例之四：不說明異常的詳細信息

　　代碼：3行-18行。

　　仔細觀察這段代碼：如果循環內部出現了異常，會發生什么事情？我們可以得到足夠的信息判斷循環內部出錯的原因嗎？不能。我們只能知道當前正在處理的類發生了某種錯誤，但卻不能獲得任何信息判斷導致當前錯誤的原因。

　　printStackTrace的堆棧跟蹤功能顯示出程序運行到當前類的執行流程，但只提供了一些最基本的信息，未能說明實際導致錯誤的原因，同時也不易解讀。

　　因此，在出現異常時，最好能夠提供一些文字信息，例如當前正在執行的類、方法和其他狀態信息，包括以一種更適合閱讀的方式整理和組織printStackTrace提供的信息。

　　結論四：在異常處理模塊中提供適量的錯誤原因信息，組織錯誤信息使其易于理解和閱讀。

　　反例之五：過于龐大的try塊

　　代碼：3行-14行。

　　經常可以看到有人把大量的代碼放入單個try塊，實際上這不是好習慣。這種現象之所以常見，原因就在于有些人圖省事，不愿花時間分析一大塊代碼中哪幾行代碼會拋出異常、異常的具體類型是什么。把大量的語句裝入單個巨大的try塊就象是出門旅游時把所有日常用品塞入一個大箱子，雖然東西是帶上了，但要找出來可不容易。

　　一些新手常常把大量的代碼放入單個try塊，然后再在catch語句中聲明Exception，而不是分離各個可能出現異常的段落并分別捕獲其異常。這種做法為分析程序拋出異常的原因帶來了困難，因為一大段代碼中有太多的地方可能拋出Exception。

　　結論五：盡量減小try塊的體積。

　　反例之六：輸出數據不完整

　　代碼：7行-11行。

　　不完整的數據是Java程序的隱形殺手。仔細觀察這段代碼，考慮一下如果循環的中間拋出了異常，會發生什么事情。循環的執行當然是要被打斷的，其次，catch塊會執行??就這些，再也沒有其他動作了。已經輸出的數據怎么辦？使用這些數據的人或設備將收到一份不完整的（因而也是錯誤的）數據，卻得不到任何有關這份數據是否完整的提示。對于有些系統來說，數據不完整可能比系統停止運行帶來更大的損失。

　　較為理想的處置辦法是向輸出設備寫一些信息，聲明數據的不完整性；另一種可能有效的辦法是，先緩沖要輸出的數據，準備好全部數據之后再一次性輸出。

　　結論六：全面考慮可能出現的異常以及這些異常對執行流程的影響。

          改寫后的代碼

 1OutputStreamWriter out =  
 2java.sql.Connection conn =  
 3try { 
 4　Statement stat = conn.createStatement(); 
 5　ResultSet rs = stat.executeQuery( 
 6　　"select uid, name from user"); 
 7　while (rs.next()) 
 8　{ 
 9　　out.println("ID：" + rs.getString("uid") + "，姓名: " + rs.getString("name")); 
10　} 
11} 
12catch(SQLException sqlex) 
13{ 
14　out.println("警告：數據不完整"); 
15　throw new ApplicationException("讀取數據時出現SQL錯誤", sqlex); 
16} 
17catch(IOException ioex) 
18{ 
19　throw new ApplicationException("寫入數據時出現IO錯誤", ioex); 
20} 
21finally 
22{ 
23　if (conn != null) { 
24　　try { 
25　　　conn.close(); 
26　　} 
27　　catch(SQLException sqlex2) 
28　　{ 
29　　　System.err(this.getClass().getName() + ".mymethod - 不能關閉數據庫連接: " + sqlex2.toString()); 
30　　} 
31　} 
32
33　if (out != null) { 
34　　try { 
35　　　out.close(); 
36　　} 
37　　catch(IOException ioex2) 
38　　{ 
39　　　System.err(this.getClass().getName() + ".mymethod - 不能關閉輸出文件" + ioex2.toString()); 
40　　} 
41　} 
42} 

         本文的結論不是放之四海皆準的教條，有時常識和經驗才是最好的老師。如果你對自己的做法沒有百分之百的信心，務必加上詳細、全面的注釋。

　　另一方面，不要笑話這些錯誤，不妨問問你自己是否真地徹底擺脫了這些壞習慣。即使最有經驗的程序員偶爾也會誤入歧途，原因很簡單，因為它們確確實實帶來了“方便”。所有這些反例都可以看作Java編程世界的惡魔，它們美麗動人，無孔不入，時刻誘惑著你。也許有人會認為這些都屬于雞皮蒜毛的小事，不足掛齒，但請記住：勿以惡小而為之，勿以善小而不為。

2005-12-17
Goingmm  Subscription

幾天沒看新聞，Hibernate已經發布3.1版本
http://sourceforge.net/project/showfiles.php?group_id=40712&package_id=127784&release_id=377721

Down下來簡單看了看。初看，沒多大變化嘛。但是關注一下Change Log.
感覺這個版本主要是Fixed 3.0的一些Bug

Change Log 部分引用

 1Changes in version 3.1  (12.12.2005)
 2-------------------------------------------
 3
 4** Bug
 5    * [HHH-849]   - Cartesian product + implicit joins
 6    * [HHH-1065] - user provided connection not usable by default due to agressive release changes
 7    * [HHH-1101] - associations join fetched in HQL without owner being selected
 8    * [HHH-1133] - Comparators, defined for collections in mapping files, are not set
 9    * [HHH-1149] - NPE flushing reattached entity  w/ non-mutable natural-id
10    * [HHH-1170] - HQL 'cast' function doesn't work with MySQL 4 when casting to string
11    * [HHH-1187] - Cannot delete a object having a delete-orphan collection when user_rollback_id is set
12    * [HHH-1191] - HQL fails backward compatibility using classic translator
13    * [HHH-1194] - hql delete statements with joined-subclass hierarchies with a mapped where attribute at the root
14    * [HHH-1206] - Mappings.TableDescription is not serializable
15    * [HHH-1212] - mismatch in entity-modes defined in DTD and EntityMode class
16    * [HHH-1227] - ClassCastException on DOM4J replicate of Calendar property
17    * [HHH-1239] - BinaryArithmeticOperatorNode.getDataType() does not properly handle date/time arithmetic
18    * [HHH-1240] - Track connection leakage in JDBCContext.afterTransactionCompletion()
19    * [HHH-1245] - Calling the Session should register it with the current JTA txn.
20    * [HHH-1254] - Serialization of Sessions using JDBCTransactions with auto-flush/auto-close
21
22** New Feature
23    * [HHH-1222] - Autodiscover scalar types in native-sql
24    * [HHH-1243] - allow placeholders to system properties in config properties
25    * [HHH-1244] - Support for MySQL5 stored procedures
26    * [HHH-1260] - Configuration.mergeProperties()
27
28** Task
29    * [HHH-1066] - Upgrade CGLIB to fix proxy memory leak
30    * [HHH-1242] - upgrade ANTLR to 2.7.6rc1
31
32** Improvement
33    * [HHH-860] - insert  select  and version numbers
34    * [HHH-926] - TypeDef should be global
35    * [HHH-1138] - No ConstraintName when using PostgreSQL
36    * [HHH-1144] - Implement naming convention for temporary test failures
37    * [HHH-1153] - PropertiesHelper fails reading primitive values from hibernate-mapping when doc has whitespace
38    * [HHH-1182] - Access to filter metadata
39    * [HHH-1183] - Getting sql "plan" for DML operations
40    * [HHH-1197] - Support for HQL delete on MaxDB
41    * [HHH-1198] - post-insert event pass the entity wo the id field filled when the generator is identity
42    * [HHH-1213] - make JACC event listeners auto configurable (through initialize(Configuration))
43    * [HHH-1215] - Added support for LVARCHAR in InformixDialect
44    * [HHH-1218] - Add concat() function support to SAPDBDialect
45    * [HHH-1255] - ThreadLocalSessionContext and Session serialization
46
47** Patch
48    * [HHH-967] - executeUpdate on StatelessSession
49    * [HHH-1172] - Missing configuration templates for the new MimerSQLDialect
50
51** Deprecation
52    * [HHH-1229] - deprecate ability for entities to not define identifier properties
53
54
55Changes in version 3.1 rc3  (17.11.2005)
56-------------------------------------------
57
58** Bug
59    * [HHH-755] - Setter / Getter for property gDate are wrong
60    * [HHH-764] - XML mapping
61    * [HHH-1034] - The connection is closed  *outside* the JTA transaction in TransactionHelper
62    * [HHH-1062] - java:comp/UserTransaction not correct for JBoss
63    * [HHH-1064] - Exception using JTATransaction in WebSphere 6
64    * [HHH-1069] - Unnecessary commas generated in select with left outer joins
65    * [HHH-1075] - New parser  "not exists" command bug
66    * [HHH-1077] - Typo in docs: "equiped"
67    * [HHH-1080] - HQL delete fails on entities with where-fragments using operators other than '='
68    * [HHH-1081] - missing parens in example code for Criteria Associations
69    * [HHH-1084] - incorrect method name "sql" in Restrictions example, should be "sqlRestriction"
70    * [HHH-1091] - Can't write transparent CurrentSessionContext for BMT
71    * [HHH-1098] - Patch for build.sh to be able to build latest version on linux
72    * [HHH-1106] - HQL "not in" generatad wrong SQL
73    * [HHH-1111] - JDBCTransaction.rollback() results in a call to Interceptor.beforeTransactionCompletion()
74    * [HHH-1128] - Column alias clashes under  certain circumstances
75    * [HHH-1146] - latest cvs(11/10/05)  hibernate3 issue with classic query
76    * [HHH-1156] - StatefulPersistenceContext not serializable when property-ref is used
77    * [HHH-1160] - Incorrect use of getGeneratedKey() for Oracle
78
79** New Feature
80    * [HHH-449] - korean hibernate reference manual
81    * [HHH-1129] - use expected-type in 'untyped' Query.setParameter()
82
83** Improvement
84    * [HHH-221] - Proxy for one-to-one with property-ref
85    * [HHH-844] - move parameter "bookkeeping" into QueryTranslator
86    * [HHH-1051] - "Compiled" native SQL queries are not cached
87    * [HHH-1061] - import.sql should allow more human readable and usable files
88    * [HHH-1078] - <dynamic-component> requires type on property
89    * [HHH-1120] - Make NamingStrategy to work nicely with HA and EJB3 naming strategy
90    * [HHH-1142] - added getSelectSequenceNextValString() and getCurrentTimestampSelectString() to TimesTenDialect
91
92** Patch
93    * [HHH-1063] - support for 'locate' function in SQLServer and Sybase dialects
94    * [HHH-1090] - Allow subqueries on criteria to obtain non-string results
95    * [HHH-1095] - Hibernate takes incorrect HasCode when a lot of CompositeKeys and Lazy loading is involved
96    * [HHH-1103] -  finalize method filter for proxies
97    * [HHH-1136] - more meaningful AssertionFailure message in org.hibernate.persister.entity.JoinedSubclassEntityPersister.getTableId()
98

       在想Class.forName 和ClassLoader.loadClass 的區別的時候。找到的一篇好文章。給有興趣的朋友推薦
       
引用：
        Java中類的查找與裝載出現的問題總是會時不時出現在Java程序員面前，這并不是什么丟臉的事情，相信沒有一個Java程序員沒遇到過ClassNotException,因此不要為被人瞅見自己也犯這樣的錯誤而覺得不自然，但是在如果出現了ClassNotFoundException后異常后一臉的茫然，那我想你該了解一下java的類裝載的體制了，同時為了進行下面的關于類裝載器之間的隔離性的討論，我們先簡單介紹一下類裝載的體系結構。
     
全文地址：http://gceclub.sun.com.cn/yuanchuang/week-9/classloader.html


2005-12-09

      外面天亮了，睜開朦朧的雙眼。
        到處找著“時間”，手機會到什么地方去了呢？
        凌晨3：50 比賽鬧鈴一響。夢中驚醒過來后，不知道把手機丟什么地方去了。

                                             The Brightest Star...
        跑不贏是有點郁悶
       
        
        群毆 從來都沒有懼過
       
        
        一手遮天 他娃可能黑手黨的小混混
        

      混混本色 跳起一耳SHI
      

      跟他們玩累了 咋哥倆就在這小睡一會吧
      

      2005-12-07 

     
       
       

      

   最近，用各種算是流行的方法寫了些Hibernate的例子(基于測試)。上次打算寫兩篇文章。① Hibernate 常用工具的配置和使用。② Hibernate 比較簡單的，基于單表操作的例子。寫了80%吧。越想越感覺意義不大。現在網上很多這方面的文章。我自己也沒有理由，自私的所謂備份。占用Blogjava的硬盤空間。就成了后來的 “冰 凍 閑 聊”
   上個星期五，因為公司停電。所以休息了三天。一年前，這個數字可能會感覺太短。但是現在卻是突然覺得連續三天不上班。不知道該干什么好。
   難道是對這種“月光”族的生活上癮拉？… 這樣的話題，等以后想明白了再說吧！~
   接著說這個周末吧！因為無聊，翻翻，去年用過的一些散亂的筆記。越看越搞笑，字跡潦草，還好基本上是一些技術痕跡。找不到從前那些“少年不知愁滋味”的感覺。
   因為我一直不是很喜歡看書。現在的書，寫得好的不多，但是價錢蠻貴的。所以，有時候就會把一些疑惑的問題寫在一張紙上。然后去網上先收集一些資料，再閱讀總結。
   這里，我發現了一條有趣的問題。2004年12月3日 Hibernate使用JDBC和JTA管理事務有什么區別？傻傻的問題。不如今天就聊聊這個話題吧！可能，現在也會有人對這個問題感覺疑惑的。

打開hibernate.cfg.xml看看具體的JDBCTransaction 和 JTATransaction 配置：

 11)
 2<property name="hibernate.transaction.factory_class">
 3org.hibernate.transaction.JDBCTransactionFactory
 4</property>
 5
 62)   
 7<property name="hibernate.transaction.factory_class">
 8org.hibernate.transaction.JTATransactionFactory
 9</property>
10

可能你還會問：“除了這兩種還有其他的選擇嗎？到底選擇那一種好呢？在一個應用中能混合使用嗎？”等等問題

分析和解答：
第一個問題
   可以選擇其他的事務管理方式。不過都是JTA的不同實現版本。這個目錄下面有羅列出來hibernate-3.0\src\org\hibernate\transaction。比如：

1<property name="hibernate.transaction.manager_lookup_class">
2org.hibernate.transaction.WeblogicTransactionManagerLookup
3</property>
4

第二個問題
   概念事務：事務就是能以整體的原子操作形式完成的一系列操作。

   是不是感覺有些饒口？簡單的說，事務 就是一個邏輯工作單元。其中包括一系列的操作。至于事務為什么會產生？有什么基本特性？等等。。這些問題今天不就詳細的羅列了。網絡上有寫得很好的文章。
Hibernate 是JDBC的輕量級封裝。他本身并不具備事物管理的能力。事務的管理和調度將委托給JDBC或者JTA去做。

    先說，他默認的事務處理機制[ JDBC Transaction ]，這的確是最簡單的處理方式，因為Hibernate只是對JDBC事物做了一層簡單
的封裝。JDBC事務由Connection管理。事務周期局限于Connection的生命周期之內。在Hibernate中這種事務周期也就局限于一個Session之內。做個比較吧！

Connection conn = …    ;      <---   session = sf.openSession();// 初始化數據庫連接，

和setAutoCommit= false;

conn.setAutoCommit(false);     <---   tx = session.beginTransactioin(); 會再次確認setAutoCommit是否是false

調用業務方法                   <---   調用業務方法

conn.commit();                 <---   tx.commit(); (對應左邊的兩句) 這里很關鍵，關掉自動commit。自己就必須做commit。否則數據是不會被持久到數據庫

conn.setAutoCommit(true);

conn.close();                  <---   session.close();

 

簡單吧！如果你對JDBC有了解，看到這里可能會壞笑，NND就這么簡單，我也會封裝…有興趣的話可以直接去看看具體的源代碼。

 
看看第二種[JTA Transaction]有什么神奇的地方吧！

   JTA 提供了跨Session的事務管理能力。JTA的事務是要容器支持的，即JTS，用來分布式的要求比較多一些，比如像銀行這種大系統，處理多個事務源的這些的。
   JTA事務管理則是由JTA容器實現。事務的生命周期完全由容器來維護。容器中可以有很多Connection。按照執行的順序，因該是串聯的一條JDBC Connection事務鏈。所以JTA的事務周期可以跨多個JDBC Connection的生命周期。在Hibernate中這種事務周期也就可以跨越多個Session。
   所以。JTA事務的Connection不能對事務管理進行干涉。意思就是，假如使用了JTA就不應該再重復調用Hibernate的Transaction功能。這里涉及到一種事務模型（嵌套式事務模型）的問題。這里也不詳細的介紹具體的幾種事務模型了。在EJB2.0規范里面也不支持這種事務處理模型。
   例如 ：

1class A 有一個方法 savePerson()
2class B 有一個方法 saveAddress()
3// Call A.savePerson() and B.saveAddress() Used JTATransaction
4class C 有一個方法 saveAll() 
5UserTransaction tx = (UserTransaction)(new InitialContext.lookup(“…”))
6A.savePerson();
7B.saveAddress();
8tx.commit();
9

 

那么下面這段代碼

1Transaction tx = session.beginTransaction();
2tx.commit();
3

就不能在class A 和 class B 中出現。

原因：session.beginTransaction()也同樣執行了InitialContext.lookup方法來獲UserTransaction的實例，tx.commit()也同樣調用了UserTransaction.commit().這樣做就會形成嵌套式的事務。在Hibernate里面是不被允許的。會導致運行期錯誤。

 

談到這里，不難看出，他們都有著自己鮮明的特點和基本的聯系。回到開頭的問題，在實際項目中該選用誰好呢？

這就需要分情況而定了。

1) 如果項目有用到Sessionbean.可能你會疑問？這時候由誰來管理事務呢？

答案：用SessionBean來管理。使用JTA會很方便。因為你完全沒有必要去理會Transaction。直接在SessionBean的部署描述符里面聲明事務就行了。

2) 自己實現一個Service類，來統一調用持久層的方法。這樣也能做到前后臺的松耦合。但是這時候你對session和Transaction的處理就需要小心了。如果系統考慮分布式就使用JTA否則就JDBC足夷。但還是有必要考慮系統的升級，變遷什么的。對session和Transaction的處理，最好不要放在DAO里面做。單獨實現一個模板類來統一做。具體的原因和做法，以后有時間再寫出來。

 

第三個問題

由于SessionFactory是線程安全的，他的創建過程非常復雜，代價極其昂貴。一個應用中最好只有一個SessionFactory。事務管理類型的選擇是在SessionFactory的屬性里面配置的。這里只能選擇一種事務管理方式。

當然，你可以說還有特殊的情況，假如，這個應用需要連接到兩臺數據庫服務器，就必須為他創建另一個SessionFactory。那么就可以選用另一種事務管理方式。表面上看這種情況是可以的。居于兩種事務的性能考慮。混和用的意義不是很大。假設這樣用+面對考慮不周全的DAO，也違背了設計原則，想想，這樣的話，因為數據庫的變動，還得回去修改DAO的代碼嗎？（可能會產生嵌套問題）

所以關于這個問題的結論就是：

在一個SessionFactory中只能選用一種事務管理

面對多個SessionFactory的時候，可以混合用，但是不推薦

2005-11-28 CTU OFFICE GOINGMM

遺憾昨天晚上的比賽沒有看。補時4分鐘？是不是裁判知道尤文又贏了，認為AC 必須得贏球啊！

這種眼神很長時間沒見著了

                     

附上：舍甫琴科  上一場的4個進球，如果單純的是為了酣暢淋漓。讓你提前墊付了未來三場的運氣，
             有些不劃算哦

                          


2005-11-28 CTU OFFICE