#
所謂的熱部署（熱發布）（下面稱為“熱部署”），就是說，在web工程發布之后，不可避免的，會遇到修改BUG的問題?，F在的熱部署就是為了解決這個問題，其功能就是說：在不停止web服務的同時，對jsp和java類進行修改，修改后的效果同時還能夠在頁面上顯示出來。節省了調試時間，提高了效率。不過，修改配置文件是個例外，如果對配置文件做修改，一定要重啟web服務。
常用的web服務器一般為tomcat和jboss，現一一做介紹。
1.tomcat熱部署
在tomcat中支持熱部署有兩種方式（在原理上來說，這兩種方式是一致的，只是放的位置不同）
a)在catalina_base\conf\catalina\localhost\中依照manager.xml定義一個xml文件，比如我的項目稱作sodoperation，我們就可以寫一個sodoperation.xml，內容如下：
<context path="/sodoperation" docBase="d:\myportal\sodoperation\src\webapp"/>
其中，path指的是你在tomcat中的項目名稱，就像manager一樣，docBase是指你的項目所在的web目錄。一直到歡迎頁面為止（也就是web-inf的前一個目錄）。但是一般來說，這個目錄中最好不要有中文，如果有的話，可以在文件開始加入
<?xml version='1.0" encoding='utf-8' ?>來試一下，即整個文件變為：
<?xml version='1.0" encoding='utf-8' ?>
<context path="/sodoperation" docBase="d:\myportal\sodoperation\src\webapp"/>
這樣就可以了，如果用這種廣告，同時使用myeclipse的部署的話，輕易不要remove，這樣會使文件都會被刪掉，不能持久。所以，建議使用第二種方法。
b)第二種方法和第一種方法在原理上是一致的，其區別就是位置的不同，這次在catalina_base\conf下的server.xml，在文件末加入：
<context path="/sodoperation" docBase="d:\myportal\sodoperation\src\webapp"/>
解釋和上面一樣，這種方法在啟動tomcat后，會在catalina_base\conf\catalina\localhost\中加入一個與第一種方法的文件。這樣保證，只要對server.xml不做修改，你可以隨便對新生成的文件刪除，對熱部署沒有任何問題
2.jboss熱部署
在jboss中做熱部署也有兩種方法，因為jobss集成了tomcat，也可以說這兩種方法是在jobss上的一個修改。
a)修改
/opt/jboss4.3/jboss-as/server/node1/deploy/jboss-web.deployer/context.xml
<Context cookies="true" crossContext="true" antiResourceLocking="true" antiJARLocking="true">
<Manager pathname=""/>
<InstanceListener>org.jboss.web.tomcat.security.RunAsListener</InstanceListener>
</Context>
加上
antiResourceLocking="true" antiJARLocking="true",重啟jboss,再用myeclipse Redeploy project的時候就不需要重啟,部署完了直接開瀏覽器預覽啦
什么才是軟件架構呢？這是一個讓人費神的事情，其實呢我覺得“軟件架構”至少應該是一個動詞，而不是一個專有名詞。那么什么才是架構呢？按照我個人的理解，架構這玩意簡約不簡單。“架構”的過程是一個把抽象轉化為具體，其中的美妙不會低于設計師創造艾菲爾鐵塔那般的感受。架構的過程會讓你變得偏執、瘋狂。至少在短時期內會為之寢食難安。那時時候你的世界之后架構二字了。有點長，希望耐心看完～～～ 哈哈！
（PS：盡管架構是與編程語言無關的事情，目前采用Java語言作為例子）
好了，很多人讀到這里會懷疑，難道J2EE業界流行的那些SSH、SSI 不是架構嗎？我的回答是“NO”，如果硬要如架構沾邊的話，那也充其量是一個架構最最低級的一種。在現在的我看來，那些只不過是一些開源框架的簡單集成，毫無技術含量可言，對于架構者本人而言，那就是通過固化的配置把這些開源框架進行一定程度的粘合，使其能互相配合完成工作。當然不是否認這個配置的過程，但是這個過程是機械化的學習，絲毫看不到自己的想法，這時的想法都被固化的配置所代替。想當年 偶也是這樣子走過來的，所以說呢，現在的我不敢談論架構的內涵，僅僅是表達出我對架構的一些想法。文以記之。
好了，經過SSH簡單的粘合之后，感覺自己很偉大，而且看是躍躍欲試的樣子，拿來做項目，這是必經的一部，從程序員到架構是一個設想與實踐相結合的一個過程。你自己架構的東西必須通過項目的實踐，才能了解是否有改進的余地。我是比較幸運的，一直以來很多項目都是我架構之后在實踐呢，在這里感謝那些曾經呆過的公司。是他們給的平臺才讓我有今天坐在這里寫文章的沖動。很多人在使用簡單粘合的SSH框架去架構你的項目，你會發現那玩意不適合做項目，太原始了，仿佛回到了石器時代，當然當時你的水平估計也就是才進化到鐵器時代吧。
第二階段了，開始嘗試修改SSH搭建的框架，新在而言還是用“框架”來形容比較的貼切一點。通過一輪或者幾輪的項目實施，你會發現其實SSH等這些也不是很完美，至少還有很多地方可以改進，這時你已經不再滿足于SSH的簡單那粘合了，開始嘗試去修改加工SSH的粘合。增加一些與SSH直接交互的隔離層代碼，這樣一來自己項目的代碼干凈了很多，SSH從入侵式到非入侵式（不可能100%），這已經是一個了不起的飛躍了。你發揮了作為人主觀能動性的權利，現在你收獲了。那改造的SSH繼續項目到項目中去實踐，也許改造后的架構在當時的你看來已經很完美了。勇者無懼，Going，開始第二階段的試水，感覺很好吧，現在的你也許長大一點了，不再從單一的技術去看待項目了，開始考慮項目的開發計劃了，有了后則一層的考慮說明你是一位勤奮好學的好孩子，已經不再是單純的Coder了，面對計劃，在看看自己的架構的“框架”，時間緊迫啊。用這玩意盡管目前代碼尤雅了很多，但是對于項目小組成員的開發進度還是幫助不大，大家需要學習的東西太多了，Spring、Struts、Hibernate ....... 這對于經驗不是很豐富的程序員而言，簡直就是噩夢?？紤]到這一點，你就開始進入第三階段的進化了
第三階段，開始思考屏蔽各種框架集成帶來的復雜性，讓不懂SSH框架的人也可以快速上手使用，為了達到這一點，又開始廢寢忘食的框架重構，增加更多隔離層的代碼。這時的框架有點架構的味道了，重構之后的你會洋洋得意，認為這是很完美的了，又去屁顛的拿去項目實戰了，這時發現你隔離之后的反而適得其反，百思不得其解啊？什么情況呢？因為你對粘合的框架內核機制不了解，這時的你要虛心學習那些開源框架了，必須是源碼級別的閱讀，了解他們的內核機制，才能寫出更好的隔離層，面對大量的源碼，必須有個入口吧，下面我簡單吧Spring的入口告訴大家：首先是Spring的Ioc容器，這是核心，主要是看init bean以及loadbean的這點內容是精髓，Aop的話比較深入了，簡單一點就是采用動態代理方式實現AOP，在高級的就是采用CgLib的動態代碼切入實現。學好這兩個之后。在學習Spring MVC 了，這是一個難點，你要吧Mvc的解析流程整理好了，在從每一個環節思考架構為和要多一個這樣的環節。（Struts1 太簡單了，Struts2太復雜了）。言歸正傳了，經歷一輪源碼的洗禮，你脫胎換骨了，SSH對你而言 使用起來游刃有余了。你再也不用為框架不熟悉費力了，這是的你充滿了自信，短期內不再關注學習框架了，更多的時間分配給了架構。這時應該進入第四階段了吧
第四階段，開始用全新的眼光以及思維去粘合SSH，不錯，很多以前的使用不當現在都讓你輕易的化解，而且開始考慮使用SSH特有的一些優勢去美化的你的架構。現在的你開始考慮的不是開始了，而是如何保證代碼的質量問題了，如何保證呢？好吧，找領導申請資源測試吧，對不起，測試團隊是很昂貴的，公司很少會配備測試團隊的，自測？小弟們才不會如此上心呢？未雨綢繆吧。架構時候為何不架構一套基于SSH的單元測試框架進來呢，好處呢可以脫離容器去測試功能，基于框架的單元測試進入了你的思考范圍。等從思考到完全融入架構的時候，你有進入一個新的階段了。編寫測試架構就是為了提高工作效率，目前面向Web的開發，很多測試都需要依賴容器，每次啟動容器調試是何等的低效啊。好了集成了自己的測試框架，小弟們高興了。也會對你刮目相看，至少編寫單元測試是一個程序員的義務，保證自己的代碼的穩定性，現在你輕松了，每天吧小弟的成果用寫的單元測試運行一次。沒問題了，不錯。下班。
第五階段，也許這一階段你的架構開始穩定，很長一段時間都會固化不變，也許到達了一個瓶頸了。單位來了狠多項目，每次你都構建一個基礎成，1次 2次 。。。N次，O-MyGod，你開始討厭這種重復的的勞作了，得，這是你的責任，你是公司的技術一把手，這些肯定有你來做。這是你開始考慮吧基礎層與業務層開始解耦。解耦出來的東東作為單獨的一個項目存放，自己手動維護，以及版本控制。新建的項目都依賴你的基礎項目在做業務開發，現在感覺好多了，不用在為項目每次都搭建了?？粗鴦e人在忙，你在一邊抽煙偷著樂吧。新在的你體會到一絲分離的快感。這不是就是所謂的程序的解耦嗎？這不過你解耦的比較徹底了，從功能和物理上都實現了解耦。恩體會到設計模式的優美了，這是你也會才會發自內心的去迷戀設計模式。這些設計模式是前輩們精華的抽象，不同的模式用于解決各種現實的業務建模。學會是一回事，靈活掌握是另外一回事。關于設計模式，是必經的過程。不僅僅是學會，關鍵是靈活使用。在合適的場景下選用合適的模式，才是正解。
第六階段了，通過之前的積累，你已經開始邁出走向架構的第一步了，之前都是為這一步的積累。好比是砍柴，之前都是磨刀了，現在才開始踏上砍柴的路途，哼著兒歌、一路進發。現在刀不是問題了，估計之前的砍柴都是刀不好，注意力都在刀上了，現在刀是沒問題了，開始轉移到觀察柴了，什么柴比較好，砍哪里可以一刀成功，這些多是經驗。映射到軟件項目就是，開始關于業務建模，不同行業的業務都有其自身的特性，如何針對這些特有的業務特性去架構框架呢，在之前的隔離層上在封裝一層業務支撐體系，這個體系可以良好的為業務系統提供強大的動力。通信、政府、金融、醫療、企業、稅務、電商。。。。等等，每種行業有有其自身的業務特色，干活去吧，都發現架構的不足了，那就繼續完善吧。coding～～～～～好了，針對業務的支撐層也開發完畢了。通過實踐運行不錯。。。。。 這時你的框架成了公司的某一業務線的開發平臺了 。。。。如果繼續留在公司，你也許會不斷完善其業務建模的支撐體系。可惜，你可能換工作，換工作就意味這換行業。之前積累的業務體系完全行不通啊～～～悲劇了，沒辦法，從小弟開始做起吧，虛心學習業務基礎 。。。。
第七階段，跳槽太多也不是壞事，經歷了幾個不同的業務線，你敏銳的嗅覺開始體驗到一些獨立與業務之外的程序處理規則。如何能搭建一套快速滿足不同業務建模的基礎模型出來，說到底業務到了底層還是各種流程，只是每個流程節點處理的內容不同（不是工作流，但有其思想）。這時候，你考慮的問題已經不是業務建模了，而是業務之外的東東，這個時候你會忘記SSH這些所謂的框架，這些都是具體的形式體現，現在你需要的是高度的抽象，抽象業務之外，流程圖是你研究的核心，因為任何程序其實都可以用流程圖去表述，如何開發一套流程配置解析引擎呢，神碼業務都是流程上的一個節點而已。只要業務流程化，按照我的配置寫入，那么他就可以運行。見山不是山的境界吧哈哈～～～ 到了這一步了，感覺架構才是正的開始了。當然框架是拋不開的，現在面臨的問題就是如何利用既有成熟的框架是完成你的這些構想，現在的框架開始考慮自己的分層了，內核層、安全層、緩沖層、ORM層、異常處理機制、國際化機制等等，是不是一項偉大的工程呢，也許Spring就是這樣子走過來的。完成了這一階段的修煉。那么你還不滿足嗎？恩的確有點就是說不出來，總是有點不滿足。現在開始討論更深層次的話題
第八階段，架構是有了，你的項目規模也越來越大了，用這個玩意的人也越來越多了，現在考慮的是如何把你的框架能快速推廣，市場是檢驗產品最好的標尺。是否具有可用性。是否能量產程序員（入門級），是否能保證代碼的質量、是否能保證出現問題的快速定位，是否能夠滿足業務擴張的需求、是否滿足性能的要求………………….. 咳咳～～一口氣說完 太累了?。∵@些問題是現在需要考慮的問題了。現在架構的推廣不僅僅是你的團隊在用，也許其他團隊也在用，可惜他們無法得到你的親授，腫么辦?開始文檔化、標準化、提供實例Demo，這些夠了嗎？對了 還不夠，100個程序員有100中獨立風格的編程方式，那就意味這有100個風險的存在，你的架構如何屏蔽或者降低這些風險呢？答案呢？就是要用你的架構去誘導他們盡量編碼風格一致。其好處不言而喻啊，統一的編碼風格意味這每個程序員都是平等的，從項目角度考慮，那就是把人的風險降低了（包括離職風險）。帶來的另外一個好處就是Review代碼的快捷，統一風格的編碼無需講解 ……. 自己體會吧。說再多也是沒用這個要親自體會的。到了這一階段感覺自己是什么？在雕琢一個藝術品？哈哈～～ 這個時候更加需要實踐，去完善你的架構。因為現在你的架構是真正的架構吧。這個需要天時地利人和多方面的支撐。能達到這一步的程序員需要的不僅僅是自己的努力了，也需要公司的大環境……………….. 這就是為何什么程序員需要找適合自己發揮的平臺。公司成了員工技術發展的桎梏。其結果就是讓其平庸，或者釋放去更寬廣的空間。哇塞。好長久的文章啊。讀者看到這里，需要休息休息了，找幾張美女圖片看看吧～～～也許我的文章讓你費力了。現在OK了嗎？架構可以了吧。恩 還是有差距的。
第九階段，見山是山，再次回歸項目中來，項目的目的是什么，盈利。這是最本質的東西。偏執也好、狂熱也罷。這是一條基準，違背這一原則的任何架構都是失敗的架構。盈利不是結果，而是項目每一步風險規避的積累。架構這是需要考慮的就是如何讓架構能在每一階段都能起到規避風險的功能呢？這是一個比較空洞的概念。但是這是必須考慮的，涉及到架構任何一個細微之處的調整。從項目開始到投產到維護。。。。這個過程，架構如何能保證每一階段的風險規避呢?；蛘咛峁┙鉀Q風險的更好的方法 ………………………..
上述為架構師修煉的過程，架構是具有中國特色的架構。不同于國外，一些老外閑的蛋疼去研究，我們都是苦逼的項目中提煉自己，利用8小時睡覺，8小時工作之外的時間去完成這一修煉，上面的文字也是本人的程序開發的成長歷史，拋磚引玉吧～～希望能對開始“架構”你提供一些參考。最后濃縮幾個字，算是文章的目的！
盈利、重構、堅持 。
關于標題，我也開始附庸文雅了。哈哈！話說軟件架構是本人這些年的一些積累，在此做一點分享，希望對即將做架構或者是正在架構的 ITer 一些參考，也許見解淺薄，還望大家多多包涵，如有異議，可私聊，禁止拍磚。
說起架構可不是一件簡單的事情，他是一個很龐大的系統骨架，但是面對到手的軟件需求，你是如何設計一個合理的架構呢？原來架構這玩意也是分第一步、第二步、第三步 ........ 以此類推，不能急于求成，這樣容易扯著蛋。要做到手中無劍，心中有劍的境界，并非一朝一夕的努力，需要長期項目的實踐，經歷無數次的失敗與重構之后再能叩開“軟件架構”這個大門的一絲門縫，從來一窺汪洋。
拿到一個軟件的合同或者是用戶的最原始的需求，很多架構師的第一直覺就是關注軟件本身的功能，有哪些功能，適合采用哪些技術選型。這對于大多數人而言，的確是沒有錯誤。但是在這之前還一點需要去做的事情 ...... 不知道大家想到了嗎？架構是基于什么環境呢？這一點在架構之前不知道讀者現在是否思考過這個問題。所謂的架構首先要了解軟件運行的軟硬件以及網絡環境。之后明確了這一點才能考慮下一步的事情，否則就有點閉門造車的感覺了。
好了，說到運行環境，這是就要從硬件環境與軟件環境分別對待了，例如：
1、硬件是采用幾層架構啊，是采用集群還是單機部署呢？ 典型的網絡架構是Http服務器 + Web服務器 + 數據庫服務器 。比較厲害的就是這些都放在一個機器上 哈哈～～～
2、軟件運行的網絡環境如何，是基于局域網還是公網呢？是否存在隔離的情況
3、硬件是什么機器呢？IBM刀片 還是 AIX系列呢
4、系統的災備設備是什么，如何運作
......... 等等諸如此類的硬件環境首先要了解。
硬件明確了，下來考慮軟件環境
1、軟件運行的環境是 Window 、Linux、Unix ，是32位 /還是 64位
2、軟件運行的Web服務器神碼 WebSphere？Weblogic、Jboss、Tomcat、GlashFish還是別的？版本號是多少，支持的J2EE規范是多少。
3、JVM是什么版本，是全新部署 還是復用甲方已經存在的軟件環境呢？
4、軟件是否與其他軟件有數據交互，交互采用什么介質
5、采用什么數據庫，版本是多少？
.......... 這些是作為軟件環境需要考慮的一些基礎性的問題
通過上述簡單的文字，好像大家有點明白了吧，其實這種事情，很簡單的，只要平時多注意點就OK了，否則等開發后去現場實施才發現什么都不配套啊。如果在架構開始之前，你已經關注這一點了，恭喜了 說明你已經具備作為架構師最起碼的嗅覺了。
上述的那些問題或多或少影響架構本身，架構是基于單機還是基于集群，這是兩種迥然不同的架構模式，很多天真的童鞋認為 單機與集群架構差不多，復制一套在部署一臺機器就OK了。其實則不然。二者存在太多的不同了，我舉一些簡單的例子哈：
在Java行業，很多開源軟件使用很頻繁，這些開源軟件本身集成了Cache，用于提高性能，單系統是單機運行的時候，一切都正常，做了集群出現問題了。Cache 惹得禍，因為你的集群并沒有把框架內部自帶的緩存集群化，還是保持各自獨立的狀態，一用戶通過A服務器修改了內容，并且刷新了Cache，但是作為集群的B服務器感知不到A對Cache的變化，依舊從自身的緩存中獲取“臟數據”，這時其他用訪問B服務器讀到的值，其實是A用戶通過A服務器修改之前的值。很繞吧。希望能理解。瓦咔咔～～～這是架構如果采用cache 需要重寫自己的Cache框架，必須屏蔽開源項目中自帶的Cached，否則出了問題都讓你莫名其妙？
數據庫部署是單機還是雙機，是熱備還是冷備，數據訪問需要讀寫分離嗎？如果硬件不支持數據庫熱切換，如何采用程序實現數據庫的熱切換？這些都是架構層次的需要直接面對的問題？ 架構師們 你們心里有底嗎？
與甲方內部的其他系統是采用什么通信方式？Socket、WS、RMI，訪問的系統之間是否有防火墻隔離，采用什么技術可以穿透防火墻阻攔呢？
以后的系統如何快速部署到對甲方的真實環境中，是手動部署還是Ant自動部署？如何做到持續集成？發送錯誤如何回退？
......................... 現在是不是覺得有點復雜呢？其實沒關系，成長有兩種，一種是汲取別人成功的經驗轉為為自己的能力，另外一種是嘗試失敗，從經歷失敗中成長，本人呢二者兼有，前幾年都是從失敗中成長，但是隨著時間的推移，發現這樣的代價真的是很大。開始虛心學習前人的經驗，從而轉化為自己的知識。
掌握軟件運行的軟硬件環境是作為架構的第一步，切記切記！
上述文字，僅僅是作為軟件架構之前需要考慮的一些大概，還有很多細節其實我也不是很了解，如有補充請回帖瓦咔咔～～～～ 軟件架構 是一件藝術品～～～ 這是我對架構的感性認識。
每次架構完我都會在一段時間把它當作是完美的藝術品去欣賞，過了新鮮期后，發現很多問題，直接重構 這樣循環不已 ............. 每次的迭代 都讓自己收獲很多！
tomcat 出現 OutOfMemoryError : PermGen space
最近在把在 tomcat 5.5 上開發的項目 deploy 到 JBoss 4.2 上時，在操作一段時間就會出現 java.lang.OutOfMemoryError: PermGen space，開始以為是代碼中存在死循環的地方造成這樣的問題，但是后來發現，出問題的地方都是隨機的，并不是某一處造成這樣的問題出現，懷疑是內存泄 露，通過增大 heap 內存的方法來嘗試，依然不行，但是同樣的問題卻并沒有在 tomcat 中出現過，難道是 JBoss 的問題？
在網上做了一番搜索得到一些相關的內容。
PermGen space的全稱是Permanent Generation space,是指內存的永久保存區域OutOfMemoryError: PermGen space從表面上看就是內存益出，解決方法也一定是加大內存。說說為什么會內存益出：這一部分用于存放Class和Meta的信息,Class在被 Load的時候被放入PermGen space區域，它和和存放Instance的Heap區域不同,GC(Garbage Collection)不會在主程序運行期對PermGen space進行清理，所以如果你的APP會LOAD很多CLASS的話,就很可能出現PermGen space錯誤。這種錯誤常見在web服務器對JSP進行pre compile的時候。
改正方法，在 run.bat 中加入：-Xms256m -Xmx512m -XX:MaxNewSize=256m -XX:MaxPermSize=256m
因為項目中引用了很多的 jar 包，而這些 jar 包中的 class 信息會被 JBoss 的 class loader 加載到 PermGen space 區域，
在 JVM 默認的情況下，該部分空間的大小只有 4M，在 jar 包非常多的情況下，顯然是不夠用的，所以通過 -XX:MaxPermSize=256m 指定最大值后即可解決問題。
另外，如果 heap 內存不足出現 java.lang.OutOfMemoryError: Java heap space 時，可以通過 -Xmx512m 指定最大 heap 內存來解決這樣的問題。
首先，需要將繼承了SimpleFormController之類的sessionForm設為true。這樣，在顯示一個新表單時，Spring會將command存放在session中，而在提交表單時，Spring會從session中取出此command，隨后立即從session中刪除存放command的attribute。如果發現在session中沒有command，Spring將其斷定為重復提交，轉而執行handleInvalidSubmit(request, response)，可覆蓋此方法負責防止重復提交的任務。
可以這么說，當setSessionForm(true)之后，如果沒有先后經歷顯示表單、提交表單的過程，就會被認為是重復提交表單。
而有一些情況下卻必須重復提交表單，如，修改數據庫的數據后，試圖寫入數據庫時因某些異常失敗，如果此時異常被當前頁面捕獲并依舊返回當前頁面，由于command已經被Spring在后臺從session中移走，因此，就被認為是無效重復提交，從而導致第二次經修改后的記錄無法正確提交到數據庫中。handleInvalidSubmit()必須考慮到這種情況。
SPRING MVC就是和STRUTS等一樣，是實現了MVC的框架，但性能比STRUTS要好，STRUTS對于每個請求都是新建一個ACTION處理，而SPRING MVC是對應到不同的方法。以下為一些核心概念：
- ACTION SERVLET：前端控制器，和所有的WEB框架一樣，是所有的請求的中心入口
- MAPPING HANDLER： 比對URL，找出負責處理的控制器
- CONTROLLER：控制器，負責處理前端的請求，返回MODELVIEW
- VIEW RESOLVER：根據CONTROLLER返回的MODEL VIEW找出負責展現的VIEW
- VIEW：由于展現內容可以有不同方式，如JSP，FREEMARKER等，VIEW就負責展現，分兩步，取得要展現的模版的路徑，使用解釋器解釋并取得最終內容。一般一個SPRING就一個展現器，如JSTLVIEW，對于不同的URL，只是JSP頁面路徑不同，從CONTROLLER返回的MODEL VIEW中取得JSP路徑，輸出最終內容
- FORM HANDLER：頁面如果有表單，就涉及到如何從表單中讀取數據或將數據綁定到表單中，表單處理器已經和CONTROLLER結合在一起了，只須繼承SIMPLE FORM HANDLER就可以，在JSP中配置COMMANDNAME值，就可以此為KEY，從MODELVIEW中取表單值或綁定值到表單中
在STRUTS中，會有一配置文件：STRUTS-COMFIG.XML，配置了所要用到的BEAN的內容，好處是直觀，但項目大了，免不了配置文件數量龐大，為了減少配置文件的數量，引入注釋，實際上可以理解為配置文件不用手寫，由容器在啟動時動態幫你生成，只須在相應代碼，如類名，方法上加上注釋，容器在解釋這些類的時候就會動態生成一虛擬的配置文件，供后續使用。具體的注釋有@CONTROLLER/@SERVICE/@REQUESTMAPPING等。
Spring MVC 3 深入總結
http://www.aygfsteel.com/qcyycom/archive/2013/07/11/401467.html
每個人都期待職位的提升和別人的認可
在國內，項目經理應該是大多數程序員比較想要的職位
這篇文章將會告訴你，要成為項目經理的一些技巧?；蛘哒f，從另外的一個角度來看項目經理這個職位。
項目經理要懂技術這個問題，在iteye上被討論了很久。各有各的觀點，我在這邊不做評論。
技術做為一個人可以掌握的技能，當然是越多越好，所以從技能方面說，懂點技術當然比啥都不懂要好
另外一方面，項目經理要和技術人員溝通，而技術人員的難以溝通是出了名的。如果脫離一些基本層面的術語，溝通到一些具體的解決方案的時候，往往和技術人員的溝通有更好的效果。而這里就會用到很多技術。
所以，從這方面說，項目經理掌握一些技術，可以說是必須的。。。
當然，類似外資公司的項目經理，完全只考慮項目進度的，那就另外說。。。
項目經理要有口才項目經理需要在團隊士氣低迷的時候，鼓舞士氣
項目經理需要在客戶溝通的時候，保持不卑不亢的氣勢
項目經理需要說服客戶和領導給予更多的資源
項目經理要有謀略辦公室政治我就不在這邊羅嗦了
我想要說的是，作為項目經理，你經常面臨很多辦公室政治的挑戰。
你至少要做到團結可以團結的力量。包括你的領導，你的下屬，你的戰友，銷售，客戶等等
你可以把你的泡妞經歷和技術人員分享，來換取他們的支持
你也可以把你賺錢的股票和他們分享
你甚至什么都不用付出，只要時不時的體現一下你對他們的關心。
光說不練，這邊整個練習題
做項目的人經常碰到的，客戶要在10天之內，完成一個功能模塊，在技術人員開看基本上是不可能完成的任務
那做為項目經理，需要怎么樣處理這件事？？
我們都知道處理結果，要么增加周期，把10天換成20天，要么刪減功能。那我們采取什么樣的手段來實現這個結果？？一方面不能得罪甲方，另外一方面要實現我們的預期。
方法：把技術人員和客戶負責人叫到一起溝通，名義上解決一些gap，實際上是讓有沖突的雙方直接面對。作為甲方，你是不能得罪的，做為技術人員，你可以站在甲方的立場和技術人員爭吵。這個時候，你要把甲方的負責人涼在一邊，讓他看你們爭吵，你們在爭吵的過程中最好要用到解決方案的具體細節，讓他聽不懂。然后時不時的回過神來，用甲方的口氣和技術人員說，這個時間已經決定了的。你和技術人員可以事先溝通好，要盡量頂，甚至發火。然后你們的爭吵就會讓負責人很尷尬，退也不是不退也不是。
結果：一般1-2個小時以后，負責人就會讓步，一般是延長周期，如果周期他決定不了，那一般是刪減功能。
思考：我們沒有得罪甲方，但是甲方順利讓步。但是我們得罪了技術人員，所以在事后，一定要誠懇道歉，除非你們已經很嫻熟
另外，這個方法是考慮到如下因素
很可能這邊提出的10天，不是最終的時間點，而是那個負責人為了自己的performance提出的，如果技術人員反對很嚴重，這個防線肯定會崩潰
還有可能是負責人不清楚最終的實現，時間也不是他定的，他也需要和上級溝通。如果他看到技術人員如此抵制，考慮到這個功能計算在自己的performance下面，他會幫你爭取更多的資源。這個時候，讓負責人和他的領導去談，會取得更好的效果。
上面都是一些基本素質，如果具備下面的幾點，會事半功倍哦！！！
幽默感：團隊粘合劑，也是化解尷尬的最好的東西
真誠：如果你做不到欺騙一輩子，那你就坦率點
嘗試用對方的角度思考：讓你發現自己的問題，發現別人的弱點。
最后，留下一個問題，如果一個團隊成功的做完了一個項目，各方面評價都很好，你猜測一下，誰在這個成功的項目中，獲利最大？