結合openfans談算法的重要性

不經意看到了程序員的一期算法專題，細細研讀多位高手（包括李開復）的文字之后，對算法的重要性重新進行了反思。我研究生畢業 2 年，一直從事 J2EE 開發，由于項目的原因，很少需要自己去設計算法，甚至 stack ， tree 這些數據結構都很少使用。還好自己也不甘于平淡，如 Effective Java ， Practical Java ， Refactory ， Design Pattern 等等這些流行書還是抽空學習，這些書的確很是經典，對我的編碼風格，模式的理解，設計能力都起到了很好的促進。也快速的由一個程序員成長為架構師（只是公司的，離真正的架構師還差得遠）。

因為項目需要，去年下半年開始全面接觸開源軟件，使用了 spring ， maven ， hibernate ， ibatis 等眾多開源軟件，也對開源軟件產生了濃厚的興趣，于是拿這些開源軟件做了 openfans ，一方面是推進開源軟件在中國的使用的交流，一方面也為自己在實踐中更多使用這些軟件（因為沒有項目和利益因素，可以做想做的事，用想用的軟件）。使用這些開源軟件倒很是順利，很多軟件拿來就能用，都有 sample ，簡單使用還是不難的。

但一些關鍵的問題一直懸而未決！比如 tag 的設計：我現在簡單的使用平鋪的模型， tag 沒有層次之分， tag 間產生雙向關聯。但這樣是最符合 tag 特性的模型嗎？如何對這些 tag 進行分類，如何定義 tag 的多級關聯（如 spring 和 hibernate 有關聯， hibernate 又與持久層關聯， spring 是否與持久層有間接關聯，依次類推）。。。。。。而做出一個好的 tag 模型，可能就需要圖論方面的知識。再比如用戶相似度設計（號稱是豆瓣的核心，難以復制）：每個用戶擁有了一些 tag ，如何根據這些 tag 定義用戶的相似度，一個用戶有 spring ， hibernate 這 2 個 tag ，一個用戶有 spring ， ibatis 這 2 個 tag ，他們相似度為多少，如果每個人 tag 都很多，再加上權重的概念，問題又復雜的多。簡單的做法就是每個用戶 tag 一個個匹配，匹配的越多相似度越大，但這樣設計一是不準確，二是時間復雜度很大，最壞情況為 n*n*m*m ， n 為用戶數， m 為每個用戶的 tag 數。

這些都需要扎實的算法基礎。而我的基礎就很薄弱：本科學的比文科還文科的專業，研究生又學的比較上層的東西（ UML ， RUP ， PM 等，也都一知半解），選修了一門算法導論，又被 1000 多頁的經典英文教材嚇趴下了，上了幾次課就直接放棄，沒敢參加最后考試。現在想臨時抱佛腳，談何容易。

所以算法也并非沒有用處，關鍵要看你在做什么，想做什么。想去 google 、百度不用會 spring ，算法基礎扎實，只會 c 語言都行；一些行業如電信、金融也很是需要算法高手。而國內更多的企業做企業應用，一般是連連數據庫，寫寫頁面，最多引入些開源框架和軟件，如 spring ， hibernate ， struts 等。這方面的需求較大，會了 spring ，省了公司的培訓成本，自然還是給找工作加了一些砝碼。

所以有時聽到某些人對某項技術不以為然，說“這些東西有什么是我在幾個星期學不會的”的時候，一方面是對其狂妄進行些鄙視，一方面也真要問問自己，我的核心價值到底在哪。這個問題很重要，涉及面很廣，選擇也很多，而我也只是有些模糊的答案，等以后再仔細寫寫。

不管如何，我是要開始研究算法了，得解決問題阿！先在 openfans 開個算法的 tag ，一邊學一邊積累，對算法有興趣的同學也可以跟我一塊進步。

PS ：做個廣告， blogjava 很多好的 bloger ，能否到 www.openfans.net 導入下 blog ，跟大家分享下你的感悟，謝謝！

posted @ 2006-07-12 15:01 pesome 閱讀(2597) | 評論 (6) | 編輯 收藏

openfans新功能，歡迎大家使用

很不好意思，不是原創技術。做個廣告，有不妥，歡迎管理員從首頁拿掉。
??? 你是開源軟件的愛好者，平時學習和使用這些軟件，也不時寫寫 blog ，記下些心得。

你是開源軟件的傳播者，你希望更多的人了解和使用開源軟件，希望你的文章被更多的人閱讀，并展開更深刻的討論。

你是開源軟件的參與者，平時參與參與國外的開源項目，也希望中國能有更多的開源團體，大家一起做國人自己的開源軟件。。。。。。

只要你對開源軟件保持著一份熱愛，歡迎來到 openfans(www.openfans.net) 。

非常方便的注冊后，你就可以點擊“提交 feed ”，只要輸入你的 rss 地址（由于時間原因，還沒做直接從 web 地址發現 feed ），就可以將你的 feed 加入，同時我們對一些網站提供了簡單的匹配（如 blogjava ，只需輸入你在 blogjava 的用戶名，系統會自動匹配成你在 blogjava 的 feed ）。完成后，點擊“立即導入”，就可以將你的文章入庫，點擊“最新日志”可以查看。以后系統會每日定期讀取你的 feed ，自動將新的文章加入。由于你提供的是 rss ，內容應該是文章的簡短描述（視你的 blog 提供商而定），而且我們會為每篇文章提供原文鏈接，直接指向你的 blog 原文。

導入的日志一般是沒有進行分類的，不方便大家的查找。在每篇日志上都有個“我要推薦”鏈接，點擊并輸入你認為適合的標簽（如 spring ， hibernate ， cms ）等，就可以把這篇日志形成文章，放在相應的標簽下，永久保存。需要學習 spring ， hibernate ， cms 的后來者，可以方便的查找到標簽和軟件，找到你的文章，進而進入你的 blog 。

同時你也可以發表文章，推薦軟件，創建和加入小組，進行評論。。。。。。我們會不斷完善功能，給大家提供更方便的功能和更好的用戶體驗。

由于現在人員較少，開發進度較慢。但先做個廣告，下一步會做 digg ，提供對軟件、文章、用戶等的 digg 。做對一些標簽的 rss ，如 springframework 網站的 rss ，自動獲取 spring 的版本更新信息。還要完善小組功能和好友功能，給大家提供一個方便交流的平臺。

網站拿 java 的一堆開源軟件做成，同時本身也是開源軟件，希望參與的同學可以 email 給 pesome@gmail.com ，大家一塊為推動開源軟件在中國的發展做出自己的貢獻。

posted @ 2006-06-09 12:42 pesome 閱讀(1344) | 評論 (6) | 編輯 收藏

maven換到jdk1.5的問題解決

? 前面openfans用的JDK1.4，今天下決心換成1.5了。運行倒是好好的，在jetty下也沒有什么問題。一不小心點了下eclipse里我做的mvn eclipse:eclipse的External Tools，就開始maven了。停也沒用了，等著吧。結果報錯：D:\javaproject\openfans\main\src\org\openfans\domain\Group.java:[29,19] -source 1.3 中不支持泛型（請嘗試使用 -source 1.5 以啟用泛型）?？戳丝?span lang="EN-US">maven的bat，會自動使用環境變量配置的jdk，應該沒問題啊。還好我網上認識人多，想起alin用的jdk1.5，就問他怎么回事。發過來這個：

< plugin >

?????? < artifactId > maven-compiler-plugin </ artifactId >

????????????? < configuration >

????????????????? < source > 1.5 </ source >

????????????????? < target > 1.5 </ target >

????????????? </ configuration >

</ plugin >

我一看就明白了， mvn 時是用 1.3 給我編譯的，得告訴它用 1.5 ?？降?/span> pom 文件中，再 mvn eclipse:eclipse 搞定。問題是很快解決了，同時卻留下了很多思考：

1． 技術沒有止境，做人一定要謙虛。 Maven2 我用的也算比較早，還曾經被白衣說是對maven2的推廣做了貢獻的，自己也頗以為然。而現在這個簡單的問題卻不知道了，還得google或問人解決。還好我一直比較謙虛（本身也沒啥可驕傲的資本），否則要狂被鄙視了。

2． 技術的推廣要不遺余力，好的東西要讓大家都知道。 Maven2 我也只是使用，了解并不深入（項目中碰到了的知道，沒碰到的就不懂了），但我是到處推薦，碰到個人就說這個好。這下很多朋友都知道了，也引入項目實踐了。一方面他們用的舒服，提高了效率，有點問題還可以向我這個所謂的maven2高手請教，我自是“知無不言，言無不盡”；另一方面，他們也許就碰到其它問題了，然后知道如何解決，在我碰到類似問題時，就可以向他們請教了。你看，多好的良性循環，想想都美滋滋的。

3． 多進行知識共享，大家的智慧比個人強。 這是從更高的角度看了，通過知識的共享，能迅速集合大家的經驗和智慧，讓個體更快的進行學習，少走彎路。你共享自己知識的同時，也能獲得別人的成果。如果你知道誰spring比較強，誰hibernate比較強，誰在用maven，而且碰到問題能看他們的文章或直接向他們請教，做起項目來是不是都安心的多?？赡苡腥苏f有google，但google信息量太大，而且很多文章是處處轉載千篇一律，經常半天找不到東西。我是深有體會，所以想到做openfans，做一個知識共享的平臺，并做到去糟取精?，F在還遠遠達不到要求，但我會努力的。

posted @ 2006-05-29 17:11 pesome 閱讀(3996) | 評論 (4) | 編輯 收藏

openfans領域模型驅動的嘗試

領域模型驅動（ Domain Driven Design ），很熱的名詞。 Openfans ，不太熱的網站。今天俺就借著很熱的 ddd ，給不太熱的 openfans 再造點勢。 Openfans 就不多介紹了，網站用 spring+hibernate 為核心的一堆開源軟件構建。有了 spring 的 IOC 和 hibernate 的 ORM ，打著 ddd 的旗號也就名正言順了很多。先聲明其實俺對 ddd 的理解也多是道聽途說，沒有什么系統的學習過，倒是和 Joe 阿牛討論過幾次，頗有受益，他對這個理解還是很深刻的。

言歸正傳，就講 openfans 現在經 ddd 思想改造過的模型。整體上看還是普通的三層架構體系：展現層、業務層、持久層。展現層用 spring mvc ，力圖做到只是展示相關，避免出現業務邏輯。再具體細分，就是 jsp 頁面只有展示邏輯，主要使用 jstl 完成顯示功能。 Controller 負責從頁面獲得參數、把數據傳回頁面、控制頁面流傳和調用業務層的接口。持久層使用 hibernate ，在設計上我不是按 dao 方式為每個對象建立相應的 dao ，也不是 ddd 推薦的每個 domain 一個 repository ，而是分成了 Persistence 和 Fetcher2 個接口。 Persistence 處理持久相關如 save 和 remove 方法， Fetcher 則處理 get 相關。這樣分的原因也很簡單， persistence 是很穩固的，對象都可以共用一個接口如 save （ Object ），而 fetcher 就千變萬化，需要分頁、排序等接口。

這樣設計是與業務層架構相關的。我采用的是 domain 對象（簡稱 DO ） + 一層薄薄 fa?ade 的方式。 DO 處理自身的邏輯，包括持久功能。本身 DO 是沒有持久能力的，需要依靠注入的 persistence 接口，這里就體現按 Persistence 和 Fetcher 分開的一個好處， persistence 所有 DO 可以共用一個，給編程帶來了方便。 Openfans 中采用的是 DO 繼承一個抽象 PersistentObject 類的方式，這樣 DO 方便的獲得了注入的能力和持久的能力。這樣做有何優缺點還需要做些討論，為了方便我也就先這么用。 PersistentObject 代碼如下：

public abstract class PersistentObject implements NeedPersist {

?????? private Persistence persistence;

?

?????? public void save() {

????????????? persistence.save(this);

?

?????? }

?

?????? public void remove() {

????????????? persistence.remove(this);

?????? }

?

?????? public void setPersistence(Persistence persistence) {

????????????? this.persistence = persistence;

?????? }

?

?????? public Persistence getPersistence() {

????????????? return persistence;

?????? }

}

這樣 DO 只需要注入 persistence 就獲得了持久的能力，而且可以把這種能力往下傳遞。 DO 獲得了持久能力，就有點接近富血模型的想法了，他能夠處理一些業務，做持久然后調用引用對象的業務和持久方法 ( 從另外的角度看持久與業務其實是分不開的 ) 。這樣把業務封裝在了領域本身，更適于用領域對象出發的方式去思考問題。領域層的 fa?ade 主要是為了 Transaction 管理和隱藏 DO 接口。這樣 DO 的業務方法都可以設置成 friendly ，僅相互間可見。 Fa?ade 就放在 domain 包中，它負責給 DO 注入 persistence bean ，調用 DO 的接口，提供給 controller 一個 use case 級別的接口，同時它也代理 fetcher 的接口。

有了這個架構，實現起來也不復雜，要配置的 bean 很少（現在還沒有使用 spring 2.0 將 DO 配置在容器中）。設計就從 DO 出發，明確它的屬性和方法，讓 hibernate 自己生成數據庫表。

?????? 這樣設計也算是一次嘗試吧，其中肯定有很多考慮不周的地方，需要不斷的討論和改進。

posted @ 2006-05-22 18:28 pesome 閱讀(1389) | 評論 (4) | 編輯 收藏

jetty與maven集成

posted @ 2006-05-15 11:19 pesome 閱讀(2045) | 評論 (0) | 編輯 收藏

bea usergroup歸來

今天下午去參加了上海的 bea usergroup 大會，主題是深入極限編程，感覺還是受益良多的。這次大會有 yanger 主持，少了很多的商業氣息，只是在中間休息階段問了一些有關 bea 產品的問題。關于 bea 我也不大熟，平時用的都是 ibm 的一套，也就不多評論了。

一共 3 個 speaker ，第一個是 thoughtworks 的資深顧問，講了些 xp 要注意的地方，并配了些照片和圖表，講如何實施 xp ，還是有些收獲的。第二個是阿里巴巴的性能測試專家，講了如何進行性能測試，如模擬用戶，確定負載等等。人挺牛的，但想想阿里巴巴每天 1 個億的 pv(page view) ，他都搞得定，咱也沒話說。

第三個出場的就是這篇文章的重點了，講的的確很好，而且很有新意。這位是紅工廠的老板，在中國工作幾年，然后去加拿大開始了他的 xper 之路，回國后做出了自己的 JDO 實現。他的主題就是結合自己的經歷，講授一個 xper 的成長過程。因為是親身所感，他講出來很是實在，加上時不時幽它一默，如：上班讓打游戲感覺很爽，跟印度美媚 pair programmer 卻感覺很累。。。。。。讓人在會意的微笑中體味他當時的感受和成長，同時加深對 xp 的一些實踐的實際認識。

他并沒有講 xp 所涉及的所有要素，只是強調了 pp 和溝通的重要性以及測試優先和重構是程序員的基本素質這幾個方面。他很是關注溝通的精神甚至一個人的性格要素，他認為好的 programmer 應該樂于去溝通，勇于承認不足，并能主動去向同伴或團隊尋求解答（而不是首先去 google ）。同時他對 xp 的精神提出了自己的看法，也是以人為本，但是另一種意義上的以人為本。他半開玩笑的說，以人為本并不是給你更多的工資，讓你上班打游戲，讓你 happy 的工作，而是把以前對流程的關注更多轉到開發人員上面，讓開發人員具備一個 xper 應有的素質。他通過親身體驗說明了一個好的 xper 即使不在 xp 的團隊中，也能創造更快的開發效率，更高的代碼質量和更少的加班。關于這點我也很是認同并有一些親身的實踐：通過測試先行，不斷重構和努力消除重復代碼，是能大大優化代碼結構，提高代碼質量，減少 bug 率的，而相應的反而會提高開發效率。

也許目前國內還較少有真正能實施 xp 的團隊，我們也很難真的在項目中進行 xp 的完整實踐。但只要我們接受 xp 的思想，在平時的實踐中就采用一些 xp 推薦的方式，如測試優先、重構、持續集成、樂于溝通等等，先把自己變成一個合格的 xper ，那么在真的有機會實施 xp 的時候，我們就能更快的融入團隊，更好的用 xp 的精髓指引項目走向成功。

posted @ 2006-04-15 23:30 pesome 閱讀(1577) | 評論 (3) | 編輯 收藏

校慶一日（繼續）

接著昨天的寫。

出了大樓，師弟帶我們到新建好的南門去看看。這不是凱旋門的模仿嗎？厚重的大理石砌出中間一大兩邊一小的空透長門，再加上一些簡單的雕飾，中間的下面卻立了很大石碑，刻上學校的名字，再圍上一些花，阻止人的通行，頓時減少了很多宏偉的氣勢。但這樣卻便于照相，好多同學三五成群往石碑前一站，然后很好取景：人面鮮花相映，加上“凱旋門”的氣勢和石碑的明喻，很有紀念意義?！皠P旋門”兩旁是弧形的長廊，仿歐洲古典主義建筑風格，一排排石柱過去，憑添了不少文化氣息。

從“凱旋門”往校園里走，眼前一片開闊，是一大片草坪，有幾個足球場大。草坪上有不少學生，或站成一圈玩飛盤，或幾個人圍坐打撲克，或幾個人亂臥其上感受草的氣息。我們走進看看，一塊塊醒目的小牌上都有一句頗有意味的話語“小草在休息，請勿打擾”。本意大家都明白，但看這么多人在上面，也就暫且從眾一把。我們也打擾了一下小草，我還忍不住在上面打了個滾。同時在想：這么大的一塊草坪，花費不菲，如果只是看看，未免可惜了點，好像國外的草坪也并不禁止人踩踏的，只要不在上面做劇烈運動，如踢足球之類，應該也不會帶來很大的影響。

沿著路往東走，右邊都是新建的教學區和學院大樓，風格很是統一。經過一座小橋，往下看去，河水緩緩流過，旁邊一個小的岸邊廣場，河岸邊有沿河走道，一直往遠方延續。在草坪的綠色基調下又多出一些點綴，真是風景這邊獨好。我又在心底感嘆：真是適合談情說愛的好地方，可惜我們那時沒有，只有西邊一個小的人工湖，晚上擁擠的很。再往東就看到一個紅漆的仿古大門，是把老校區的大門 copy 過來了。照樣門前一對石獅，也是適合攝影留戀的地方。

大家到這也就慢慢散去了，大部分打的走了。我的愛車還在學院門口停著呢，于是又跟幾個同學往里走。一邊聊聊工作的事情，一邊大家好像有默契的往以前的宿舍樓所在走去。走了好遠，過了一個地道，來到以前的宿舍樓下。又翻新了，涂上淺黃色涂料，加上四角的紅磚墻裝飾?？上г揪驼w感覺不佳，就好像一個丑媳婦，涂上再多胭脂水粉也變不成美女一樣。忍不住從下往上張量以前我住的宿舍，陽臺掛了件運動衫，里面還是有位運動健將的。

又得睡覺了，還沒寫完，明天繼續。

posted @ 2006-04-09 22:53 pesome 閱讀(840) | 評論 (6) | 編輯 收藏

校慶一日

今天是母校 110 周年校慶，同學一塊回去看看闊別了快 2 年的校園。我可是有車一族，便開車回去看看，不遠的路，開了 1 個小時，挺累，是自行車。早聽說短短 2 年，學校擴大了好幾倍，但真的到了還是頗有感慨。從東邊一個門進去，一直往西騎，新造的大樓一座座被拋在后面，完全是陌生的感覺。好久才喚回一些熟悉的記憶，原來是到了以前的東區了。我以前在西區住，到東區的新教學樓上課，就感覺遠的厲害，走路需要十多分鐘的?，F在看來，自行車應該是每個學生的必需品。到了西邊還是熱鬧了很多，有了校慶的氣氛，隨處可見坐滿校友的大巴和各種款式的轎車。等俺有錢了，也開輛小車來顯顯，我心里嘀咕著。

因為趕時間去聚會，所以也無心流連，騎車直奔飯店。老同學好久不見，免不了一些客套寒暄， 2 年時間畢竟太短，大家也沒有太大的變化，沒有誰一下飛黃騰達的。席間觥籌交錯，自不必說。有 2 個研二的師弟，便吃完帶我們四處走走，首先就去看我們畢業后才落成的軟件大樓。

這時我的車發揮優勢了，他們得做校內巴士，繞好大一圈的，我就沿著一條直線直接騎過去。根據師弟的描述，來到一座銀灰色玻璃幕墻的大樓前，停好車，他們還沒到，便在外面轉悠轉悠。五層樓高，挺現代的設計，對一些細部處理的也不錯，有挑臺，凹進，凸出，顯得整個立面挺豐滿。這里插一句：我本科是在這學建筑設計的，可惜沒天賦，學了個半吊子，只好改行。

等了會，他們才姍姍來遲，大家一塊進去看看。廳很大，展出了很多學生的成果，挺不錯的，有自己開發的工作流，有拿 spring+hibernate+velocity 做的項目，有自己做的負載均衡服務器。。。。。。二點感受，一是學校教的還不錯，是在培養學生的實際能力，跟社會接軌；二是開源軟件深入人心，在校的學生也都在使用了?？戳怂麄兊膶嶒炇?，全 dell 的液晶，空間按公司的 cube 方式布置，大家議論說比他們的辦公環境還好，于是紛紛感嘆，生不逢時，晚來幾年就好了。

得睡覺了，先寫這么多，明天接著寫。

posted @ 2006-04-08 23:57 pesome 閱讀(766) | 評論 (1) | 編輯 收藏

sf上將cvs切換成svn經驗

Sf 的 cvs 一直不好，也不知道什么原因 . 前面聽白衣說過，可以一鍵切換到 svn. 今天就試了試，找了半天，在 admin-> svn 下找到了 migrate 這個鏈接，點一下進入 migrate 界面，什么都不用改，直接點下面的確認按鈕就搞定。這時的狀態是 wating ，號稱要等 1-3 小時才能搞定。我等不及，隔了一會就刷新，結果狀態已經變成 complete 了。

svn 地址為 :https://svn.sourceforge.net/svnroot/openfans/
然后拿小海龜試了下 , 可以訪問 . 拿 svn 的 eclipse 插件下載也成功了 , 通過 updatesite 可以下載這個插件 (http://www.polarion.org/projects/subversive/download/update-site/) 。打開插件窗口，界面跟 cvs 基本類似，我先試 commit 功能，正好把前面 cvs 的本機改動提交上去。

結果報 403 forbiden 錯。 Google ，看到白衣也碰到同樣問題，結果遷到 scud 上去了。我只好點些老外的論壇回復看，看到一個解決問題的回復。號稱要 admin->member ，我便照做，一看多了個 svn 的 permission 框，把自己的先勾上， Update 。然后重新 commit ，搞定。 Sf 的 svn 速度飛快，比 cvs 快多了，這下也省得自己搞 svn 了。把這個成功經驗寫出來，也可以給后面的人一個參考。

posted @ 2006-04-05 12:15 pesome 閱讀(1811) | 評論 (1) | 編輯 收藏

openfans快速配置指南

應牛牛和 lucky 的要求，寫一份 openfans 的快速配置指南，也就是介紹如何在你的機器上把下載下來的 openfans 跑起來。首先使用 maven ，需要下載 maven ， www.openfans.net 里可以輸入 maven 進行搜索，有它的介紹和主頁，還有我寫的一篇簡單的 maven 上手文章。

如果使用 eclipse ，在項目根目錄，也就是 pom.xml 所在目錄，運行 mvn eclipse:eclipse( 如初次使用，會花較長時間到網上下載 plugin 和 jar ，建議去喝杯咖啡 ) 。 mvn eclipse:eclipse 會生成 .class 和 .project 文件，可以進入項目的 build path 查看，會自動將 output 路徑設為 target/classes 。默認數據庫使用 mysql ，如果希望馬上運行，則創建一個新數據庫，可以命名為 openfans ，如果 mysql 采用默認安裝，則用戶名 root ，密碼為空，可以無需更改 jdbc 配置文件。要更改也很簡單，在 main/src 下面有一個 jdbc.properties 文件，可以在這里更改數據庫類型和用戶名密碼。這里有一句 hibernate.hbm2ddl.auto=update ，表示 hibernate 會自動更新建表語句，也就是新運行或更新了 hbm 文件再運行， hibernate 都會自動幫你完成數據表的重建工作，這樣你可以不用再考慮數據庫建表腳本了。

如果想在 tomcat 里直接運行，則可以執行 mvn package ，會運行所有 test case 。目前的 test case 通過繼承 AbstractTransactionalDataSourceSpringContextTests ，能夠方便的實現數據庫回滾，在 BaseTest 類下有一句 this.setDefaultRollback(false) ，如果希望通過程序填充數據，就 uncomment 它。這里有一個地方要注意一下，就是 web/WEB-INF/urlrewrite.xml ，這是 urlrewrite 的配置文件， urlrewrite 的描述在 openfans 網站里有，可以通過搜索 urlrewrite 快速的找到。因為我把文檔根設為“ / ”，所以有 <to type="redirect">/view$1.html\?id=$2</to> ，如果文檔根是 openfans 則需在 /view 前加上 /openfans ，然后再運行 mvn package 。測試全部通過，就會在 target 目錄下生成 openfans-o.1.war ，將這個 war 放到 tomcat 的 webapps 下，啟動 tomcat ，應該就能通過 http://localhost:8080/openfans 訪問了（假定你采用默認端口 8080 ）。

如果進行開發，可以安裝 eclipse-tomcat 插件，插件也可以在 openfans 網站輸入 tomcat 進行搜索?？梢栽?/span> tomcat 的 conf/Catalina/localhost 下創建一個 openfans.xml ，內容如下：

<?xml version="1.0" encoding="UTF-8"?>

<Context path="/openfans" reloadable="true" docBase="D:/javaproject/openfans/web">

</Context>

docBase 改成你的 openfans 所在的路徑。
???這里因為pom文件定義的默認輸出位置為target，需改為web-inf/classes，這時會有一個src沖突，需把src/web/里的web-inf/classes exclude掉就可以了。
然后在 eclipse 啟動 tomcat ，同樣可以通過 http://localhost:8080/openfans 訪問了。用這種方式啟動 tomcat 可以進行調試。

?

posted @ 2006-04-01 21:05 pesome 閱讀(3544) | 評論 (11) | 編輯 收藏