grails 有一個(gè) wicket 的插件：

http://graemerocher.blogspot.com/2007/05/grails-wicket-wonders-of-grails-plug-in.html

我試了一下，發(fā)現(xiàn)最新版本(0.3)的wicket插件，運(yùn)行helloworld都有問(wèn)題，錯(cuò)誤是：

wicket.markup.MarkupNotFoundException: Markup not found.

查看了一下原因，按照文檔， HelloWorld.html 是放在 grails-app/views 目錄下的，但是 wicket 插件 沒(méi)有修改classpath 和 resource 裝載的路徑，也就是說(shuō)，實(shí)際上這個(gè) HelloWorld.html 對(duì)于 wicket 來(lái)說(shuō) 是不可見(jiàn)的。但是如果把這個(gè) HelloWorld.html 放在 src/java 目錄下，則可以正常運(yùn)行。
想到了一個(gè)簡(jiǎn)單的解決方案，修改 $GRAILS_HOME/scripts/Package.groovy，在 146 行增加：

就像 src/java 當(dāng)中的資源一樣，全部拷貝到目標(biāo)目錄下，這樣的效果就和放在 src/java 目錄下一樣了。

主站： http://blogsite.3322.org/

首先看看我前幾天的一篇blog

spring 與 osgi的第一個(gè)障礙

eclipse3.1, spring2.0.1，將spring.jar放到一個(gè)插件中，在另一個(gè)插件中去使用。 最簡(jiǎn)單的例子，在context.getBean的時(shí)候就報(bào)了一個(gè)異常：

先是搜了一遍，沒(méi)有發(fā)現(xiàn)很有幫助的內(nèi)容。然后跟了一下，發(fā)現(xiàn)還是因?yàn)閤sd的映射找不到。而造成這個(gè)問(wèn)題的原因， 是在 spring.jar當(dāng)中的META-INF/spring.schemas 這個(gè)找不到。

而這個(gè)找不到的最根本原因，是因?yàn)樵趀clipse當(dāng)中，META-INF目錄是不能夠被其他插件找到的。也就是說(shuō)，META-INF 目錄是擁有spring.jar的那個(gè)插件所獨(dú)占的，而其他插件就算依賴于這個(gè)插件，也是無(wú)法找到META-INF目錄下的文件， 從而拋出這個(gè)異常。

解決問(wèn)題的辦法有幾個(gè)，最簡(jiǎn)單的莫過(guò)于拷貝spring.schemas文件到需要的插件中，另一個(gè)辦法是把spring的context 裝載就放在spring.jar所在的插件中，或者改eclipse的代碼。 :(

這個(gè)問(wèn)題解決之后，緊接著第二個(gè)問(wèn)題就是

造成這個(gè)的原因和第一個(gè)類似，將spring.handlers拷貝到META-INF目錄下就ok了。

上面是我以前的一個(gè)經(jīng)驗(yàn)，今天仔細(xì)研究了一下，發(fā)現(xiàn)自己掉進(jìn)了 經(jīng)驗(yàn)主義的圈套。

這個(gè)經(jīng)驗(yàn)是這樣積累起來(lái)的：在剛開(kāi)始嘗試使用eclipse的時(shí)候，用的是3.0和3.1Mx系列，當(dāng)時(shí) 不知道osgi是個(gè)什么東西 :$ 創(chuàng)建的幾個(gè)插件，都沒(méi)有創(chuàng)建osgi bundle manifest。也就是說(shuō)， 只有plugin.xml，而沒(méi)有META-INF/MANIFEST.MF文件的。但是在運(yùn)行期，eclipse會(huì)自動(dòng)的 從plugin.xml當(dāng)中讀取信息，生成臨時(shí)的MANIFEST.MF文件，放在 runtime的 configuration/org.eclipse.osgi/manifests 目錄下。而生成這個(gè)MANIFEST.MF文件，是 通過(guò) PluginConverterImpl 這個(gè)類來(lái)實(shí)現(xiàn)的，在它的 isValidPackageName 方法中，所有的 META-INF或者以META-INF開(kāi)頭的目錄，都不會(huì)被自動(dòng)的export出去，從而在臨時(shí)生成的MANIFEST.MF 文件中，永遠(yuǎn)不會(huì)有META-INF目錄的export。

當(dāng)時(shí)剛開(kāi)始接觸eclipse和osgi，根本不知道自己當(dāng)時(shí)最佳的解決方案就是創(chuàng)建一個(gè) bundle manifest， 然后在其中將META-INF目錄export出來(lái)。而是通過(guò)盲目的修改代碼來(lái)繞過(guò)這個(gè)彎。后來(lái)這個(gè)彎繞過(guò)去了， 留給我的經(jīng)驗(yàn)就是：META-INF這個(gè)目錄，是插件獨(dú)享的，別的插件不允許訪問(wèn)的。

于是，在前幾天，當(dāng)spring.jar當(dāng)中的幾個(gè)META-INF目錄下的文件訪問(wèn)不了時(shí)，我也認(rèn)為這個(gè)經(jīng)驗(yàn)有用， 差點(diǎn)就去改eclipse的代碼了。幸好嘗試了一下，把spring.jar所在的插件中，將META-INF目錄共享出來(lái)， 居然就好了。仔細(xì)查了一下，發(fā)現(xiàn)屏蔽META-INF的代碼只出現(xiàn)在PluginConverterImpl這個(gè)類當(dāng)中。 回頭想了想，終于明白自己這次是掉在經(jīng)驗(yàn)主義的坑里面了。

經(jīng)驗(yàn)主義害死人啊。唉。

主站： http://blogsite.3322.org/

SUN Tech 2006第一天

會(huì)場(chǎng)設(shè)在最擁堵的北四環(huán)中路，趕到會(huì)場(chǎng)已經(jīng)接近9點(diǎn)，匆忙報(bào)道之后，
第一感覺(jué)是不像去年那么大的場(chǎng)面了，只有兩個(gè)會(huì)場(chǎng)，而且很奇怪的是，
參展的其他廠商，也只有AMD一家，顯得有點(diǎn)冷清。

James Gosling又一次出現(xiàn)了，不過(guò)做的演講并沒(méi)有很多新鮮的東西，值得
注意的倒是Ruby on Rails出現(xiàn)在他的演講內(nèi)容當(dāng)中，這大概也與JDK未來(lái)版本
要支持動(dòng)態(tài)語(yǔ)言，以及SUN把jruby的兩個(gè)人招進(jìn)去有一系列的關(guān)系。隨后有
一個(gè)SUN的技術(shù)展示，其中有意思的一個(gè)是 SPOT(Small Programmable Object Tech)，
有點(diǎn)象《少數(shù)派報(bào)告》當(dāng)中阿湯哥用的手套，用手套來(lái)當(dāng)做鼠標(biāo)一樣的在
空中使用，很是不錯(cuò)。

隨后一整天的演講，給我的感覺(jué)，重頭戲是Netbeans，其次是Ajax，再其次是
Java EE 5。感覺(jué)今天一系列的活動(dòng)都與Netbeans有關(guān)，Ajax和Java EE 5包括
Java ME，都時(shí)不時(shí)的與Netbeans掛上鉤。從今天被Netbeans洗腦的結(jié)果來(lái)看，
Netbeans現(xiàn)在確實(shí)越來(lái)越好用，功能也越來(lái)越強(qiáng)大。Eclipse如果按照現(xiàn)在的發(fā)展
速度，確實(shí)有些危險(xiǎn)。不過(guò)，從另一個(gè)角度看，有競(jìng)爭(zhēng)才能促進(jìn)發(fā)展，也不算是件
壞事。

其他方面的收獲，包括對(duì)JAVA SE 7 的一些特性了解，Java EE 5的一些介紹，以及
關(guān)于Java EE 5的參考實(shí)現(xiàn) GlassFish的介紹，順便還聽(tīng)了一些Java ME的東西，也
有些意思，可惜暫時(shí)用不上。

今天有一些感觸：
?
好的技術(shù)，如果沒(méi)有好的工具支持，也是很難生存的。這就聯(lián)想到我們自己的IMP框架，
過(guò)去將重點(diǎn)放在framework和engine上，而對(duì)于designer的投入則遠(yuǎn)遠(yuǎn)不夠。這樣造成的現(xiàn)
象就是限制了開(kāi)發(fā)效率，從而沒(méi)有能夠最大的發(fā)揮IMP框架的作用。

Netbeans雖然好用，也能夠從一定程度上提高生產(chǎn)力。但是我還是那種觀點(diǎn)，看上去
很美的代碼生成機(jī)制，往往只是節(jié)省了“創(chuàng)建”的時(shí)間成本，而對(duì)于“修改”的效
率提高，卻不一定有幫助。

JSF感覺(jué)還是沿襲了Struts的東西太多，就算通過(guò)Ajax的render，感覺(jué)還是不能算非常好的
Component Framework。還是不如Echo2 ;)

回家的時(shí)候，正趕上北四環(huán)的擁堵高峰，回到家已經(jīng)很晚了，寫(xiě)的很零亂，不知道明天
會(huì)不會(huì)有什么大的收獲。反正今天感覺(jué)就是被洗了一天的腦，害得我都想裝一個(gè)Netbeans
來(lái)玩玩了。

SUN Tech 2006第二天

又經(jīng)歷了痛苦的2個(gè)小時(shí)到達(dá)了會(huì)場(chǎng)，今天的SUN公司主題居然是“開(kāi)源的好處”，
重點(diǎn)提出開(kāi)源最終有利于開(kāi)源者，號(hào)稱SUN從OpenSaloris的開(kāi)源當(dāng)中獲得了很多
好處。不知道前幾年大家強(qiáng)烈要求SUN 開(kāi)源的時(shí)候，是不是也是這種論調(diào)。也懶得
去查以前的新聞了，不過(guò)總算逐漸有將Java開(kāi)源的打算了，而且SUN號(hào)稱要將所有的
軟件開(kāi)源，這對(duì)于open source社區(qū)，也算是件好事。

今天總的來(lái)說(shuō)內(nèi)容不是很豐富，這一次的Tech Day，總共也就是幾個(gè)人在講，一個(gè)人
講好幾場(chǎng)，這在以前的Tech Day是很少出現(xiàn)的。

今天的收獲如下：

聽(tīng)了一場(chǎng)關(guān)于swing和美化swing的講座，感覺(jué)SUN對(duì)于java的投入，比以前更大了。
以前，關(guān)于swing的微詞很多，也有很多不好用的反饋，但是在幾個(gè)jdk版本的發(fā)布過(guò)
程當(dāng)中都沒(méi)有改進(jìn)，最典型的莫過(guò)于ContentPane，"Lastly, after seven years, we've made
jFrame.add equivalent to jFrame.getContentPane().add()."。在JDK5之后，可以感覺(jué)到SUN
對(duì)于用戶社區(qū)的反饋開(kāi)始逐漸重視。對(duì)于swing當(dāng)中的功能較弱的問(wèn)題，專門(mén)整了一個(gè)
swinglab來(lái)解決。其中還有個(gè)swingx的子項(xiàng)目，也有不少的swing功能增強(qiáng)組件可以用。

Apache Derby，也就是原來(lái)IBM收購(gòu)informix時(shí)收購(gòu)到的Cloudscape，現(xiàn)在又有了一個(gè)新
名字叫 Java DB，而且會(huì)隨著JDK6一起發(fā)布。Java DB的功能比較完善，據(jù)說(shuō)性能也不
錯(cuò)，號(hào)稱支持300G的數(shù)據(jù)量沒(méi)有問(wèn)題。如果這樣的話，不僅hsql可以拋掉，而且說(shuō)不定
mysql也可以不用了。我現(xiàn)在也很喜歡這種既可以embed，又可以做為cs的數(shù)據(jù)庫(kù)，現(xiàn)在
做rails的就是用sqlite，感覺(jué)也夠用了。Java DB還有個(gè)很強(qiáng)的功能是，可以將數(shù)據(jù)打包為
jar文件，做為只讀的db，放在光盤(pán)或者其他地方，做為備份和還原，以及做demo應(yīng)用放
在光盤(pán)上，應(yīng)該都有很大的用處。

JDK for script language. 在JDK6當(dāng)中，已經(jīng)支持 ruby和javascript兩種腳本語(yǔ)言了。
功能上感覺(jué)有點(diǎn)象BSF，但是由于隨著JDK6一起發(fā)布，所以以后影響力會(huì)更大。
而且，做演講的人也提到，jruby的開(kāi)發(fā)者進(jìn)入SUN公司，恐怕不只是用ScriptEngine
支持script語(yǔ)言這么簡(jiǎn)單。今天體驗(yàn)了一下印度人說(shuō)英語(yǔ)，確實(shí)是強(qiáng)...

另外還聽(tīng)了一下 MBean，Concurrence方面的東西，收獲也有一些。例如在JDK6當(dāng)中，
MBeanServer缺省就啟動(dòng)了，而不像JDK5里，需要用一個(gè)命令行參數(shù)才能啟動(dòng)。
兩天下來(lái)，感覺(jué)這一期的SUN Tech Day和以往最大的區(qū)別就是，這一期完全是被
SUN自己壟斷了，沒(méi)有別的公司演講， 不討論別的公司的內(nèi)容，沒(méi)有別的公司參展。
言必稱 NetBeans，操作系統(tǒng)必稱 Solaris。從一個(gè)角度來(lái)看，SUN公司確實(shí) 積極的
參與到了開(kāi)源社區(qū)當(dāng)中，并且比以前更加接近用戶，也更積極的響應(yīng)用戶的request。
這一點(diǎn)，從Netbeans的進(jìn)展神速， 到JDK最近幾個(gè)版本的新特性增加速度，都比JDK5
以前要好很多。這對(duì)于Java的進(jìn)一步發(fā)展，可以說(shuō)是一件好事。從另一個(gè) 角度來(lái)看，
這一屆Tech Day表現(xiàn)出來(lái)的情況，不知道是應(yīng)該說(shuō)SUN更加有了自主意識(shí)，還是應(yīng)該說(shuō)
SUN確實(shí)沒(méi)有很好的組織 這次會(huì)議。從參加演講的人員，到展廳的布置來(lái)看，
都不如往屆。不知道是不是SUN財(cái)務(wù)緊張?jiān)斐傻模琱oho.

又花了兩個(gè)小時(shí)才從首堵北京的北四環(huán)中路到了家，感覺(jué)今年的Tech Day，
最大的收獲是被洗腦了，也體會(huì)到了目前最火爆的Ajax是如何的火爆。

主站: http://blogsite.3322.org/jspwiki/ 代碼的衛(wèi)生、習(xí)慣及其它...

最近忙，發(fā)現(xiàn)家里開(kāi)始臟亂差了。仔細(xì)想想，其實(shí)之所以會(huì)這樣，
是因?yàn)榻?jīng)常發(fā)現(xiàn)有點(diǎn)臟的地方，也懶得動(dòng)，總是想等到啥時(shí)候大掃除
一下子全部清理干凈。后來(lái)地面越來(lái)越臟，就越來(lái)越不注意，進(jìn)入了
一個(gè)惡性循環(huán)。

不禁聯(lián)想到“破窗戶”理論，有個(gè)破窗戶的社區(qū)，會(huì)逐漸變得不適合居住。
又想到一個(gè)經(jīng)常看到的現(xiàn)象，如果一個(gè)電線桿下有一包垃圾，只要清理
不及時(shí)，過(guò)段時(shí)間，這個(gè)電線桿就會(huì)變成一個(gè)垃圾堆。

扯這么多，其實(shí)想說(shuō)的是代碼的衛(wèi)生。代碼，剛開(kāi)始都是很干凈的，只是
隨著時(shí)間推移，隨手亂扔的果皮紙屑逐漸增多，最后開(kāi)始發(fā)臭，然后這個(gè)
代碼就沒(méi)有人愿意去碰了。在項(xiàng)目中，經(jīng)常碰到這樣的情況。同樣的功能，
哪怕以前曾經(jīng)有人寫(xiě)過(guò)，很多人還是傾向于自己重頭開(kāi)始寫(xiě)。原因是什么？
程序員只信任自己的代碼，這是其中的一個(gè)原因。另一個(gè)原因是，以前的
代碼確實(shí)有個(gè)需要學(xué)習(xí)上手的時(shí)間。打個(gè)比方，一間房子，不適合居住，需要
進(jìn)行一番打掃才能住進(jìn)去，這就是已有代碼。而新的代碼，則是程序員親手
壘起來(lái)，親手裝修的，雖然耗時(shí)長(zhǎng)，辛苦，但是心理感覺(jué)好。但是呢，這個(gè)
新房子對(duì)于其它程序員來(lái)說(shuō)，已經(jīng)時(shí)一個(gè)堆滿垃圾不適合居住的舊房子了。
于是，每個(gè)程序員都親手建一個(gè)房子，如此重復(fù)下去。

那么，要避免這種無(wú)意義的重復(fù)勞動(dòng)，一方面是程序員本身意識(shí)的糾正。打掃
一個(gè)舊房子，雖然臟一點(diǎn)，但是通常比新建一個(gè)房子還是要快和省力。另一個(gè)
方面，程序員應(yīng)該有這樣的信念，不能讓自己的代碼變成垃圾堆。也就是說(shuō)，
不能容忍自己的代碼中堆滿垃圾。

如何避免代碼成為垃圾堆？個(gè)人認(rèn)為，就象“破窗戶”理論一樣，不能對(duì)破了
的窗戶聽(tīng)之任之，而要盡快修復(fù)。否則的話，其他人看到第一袋垃圾在這里，
覺(jué)得扔第二袋垃圾就沒(méi)有罪惡感，至少罪惡感不那么強(qiáng)。大家可以想象一下，
在一個(gè)窗明幾亮的環(huán)境中，你扔果皮紙屑之前都會(huì)三思。但是站在一個(gè)垃圾堆
上面，你扔垃圾之前就不會(huì)有什么顧慮了。因此，保持衛(wèi)生的一個(gè)好習(xí)慣就是，
不放過(guò)第一個(gè)垃圾。

當(dāng)然，如果判別某段代碼是不是垃圾，或者及時(shí)發(fā)現(xiàn)第一段垃圾代碼，那就是
另一個(gè)話題，例如用ut，用code review，等等。《Working Effectively with Legacy Code》
這本書(shū)里面，提到了Legacy code 的定義：

Code without tests is bad code. It doesn't matter how well written it is;
it doesn't matter how pretty or object-oriented or well-encapsulated it is.
With tests, we can change the behavior of our code quickly and verifiably.
Without them, we really don't know if our code is getting better or worse.

有人會(huì)覺(jué)得我管的太細(xì)，不揪架構(gòu)、設(shè)計(jì)，反而去管代碼，只見(jiàn)樹(shù)木不見(jiàn)森林。我個(gè)人
的看法，架構(gòu)、設(shè)計(jì)再好，都需要代碼來(lái)進(jìn)行實(shí)現(xiàn)。如果這個(gè)基礎(chǔ)沒(méi)打好，以后這個(gè)
代碼總是會(huì)變成無(wú)人想碰的垃圾堆。

當(dāng)然，我也反對(duì)無(wú)意義的追求完美。我不是個(gè)有潔癖的人，所以，代碼到什么程度就算是
干凈的了？我個(gè)人的看法是，Clean code that works。當(dāng)然這一點(diǎn)其實(shí)不容易達(dá)到，但是
做為一個(gè)程序員，我還是努力去追求這一點(diǎn)的。

主站： http://blogsite.3322.org/jspwiki/
在上次的文章當(dāng)中，把 eclipse做為web framework的核心，并且使得 servlet 的定義和mapping做為擴(kuò)展點(diǎn)，確實(shí)狠 方便。不過(guò)現(xiàn)在又面臨一個(gè)問(wèn)題，有個(gè)歷史遺留系統(tǒng)當(dāng)中，有jsp 的應(yīng)用。而jsp與servlet 的一個(gè) 很大的區(qū)別在于，它需要用 javac 去做編譯。這就使得問(wèn)題復(fù)雜化了，特別是使得 class loader 的關(guān)系變得更復(fù)雜。

我們首先看一下這里面有幾種 class loader，首先，啟動(dòng) eclipse 的是一個(gè)system loader，然后 是 eclipse starter 的 loader，啟動(dòng)我們的核心class loader，這個(gè)核心負(fù)責(zé)啟動(dòng) jetty 和我們 的 web app兩個(gè)插件，每個(gè)插件都有自己的 eclipse bundler loader。而jetty插件啟動(dòng)jetty 應(yīng)用服務(wù)器，應(yīng)用服務(wù)器本身有 context class loader，它還要負(fù)責(zé)去裝載 WEB-INF/lib 下的所有jar文件，以及 WEB-INF/classes 目錄下的文件，做為編譯期使用。

這里不僅class loader 眾多，而且關(guān)系復(fù)雜。一不小心就容易拋出 class not found 異常，或者是 class cast 異常。相對(duì)而言，只支持servlet 就狠簡(jiǎn)單，因?yàn)橹灰?servlet 的 context class loader 用 eclipse bundler loader 替換掉就行。而jsp的編譯機(jī)制，導(dǎo)致了問(wèn)題的出現(xiàn)。

我對(duì)于這種復(fù)雜classloader情況的心得，就是把錯(cuò)綜復(fù)雜的 class loader 關(guān)系網(wǎng)拉直，變成一棵 樹(shù)。這樣的好處就是，對(duì)于loader 的關(guān)系比較清晰，出現(xiàn)ClassNotFoundException和 ClassCastException這兩種情況的時(shí)候，都狠容易判斷怎么回事，不會(huì)被繞暈。這種時(shí)候，單步跟蹤 只是找死，把classloader關(guān)系畫(huà)出來(lái)，有利于對(duì)問(wèn)題的分析。

于是畫(huà)了這樣一個(gè)圖，把復(fù)雜的網(wǎng)拉直了，問(wèn)題就迎刃而解了。

其中的關(guān)鍵就是 LauncherClassLoader。這個(gè)就是我們自己的ClassLoader，把它設(shè)置為 servlet context classloader 的 parent，并且把 context classloader 的裝載順序改變成為先由parent 裝載，再自己裝載的模式。這樣，jsp的編譯還是由 context loader 去處理，我就不管了。其他的 該裝載的地方，還是有 eclipse bundler 去裝載，這樣問(wèn)題基本解決。

不過(guò)這樣其實(shí)還是有個(gè)問(wèn)題，如果要在 jsp 當(dāng)中調(diào)用某個(gè)插件當(dāng)中的 class，那么在編譯期就會(huì)出現(xiàn) 問(wèn)題。不過(guò)由于目前只是解決 legacy jsp 應(yīng)用的問(wèn)題，所以這個(gè)暫時(shí)不存在。我能想到的解決方案 其實(shí)也狠簡(jiǎn)單，把這些 jar 文件的url也做為擴(kuò)展點(diǎn)出現(xiàn)，那么當(dāng)jsp需要某個(gè)class時(shí)，只要把它 所需要的 jar 文件的 url 做為一個(gè)擴(kuò)展，在 LauncherClassLoader 當(dāng)中將這些jar文件添加到 url loader 當(dāng)中，而這些 url 會(huì)出現(xiàn)在 jsp 的編譯class path當(dāng)中。

主站：http://blogsite.3322.org/jspwiki/

一直以來(lái)，eclipse 對(duì)于 fragment 的概念都是一種補(bǔ)充，而不是覆蓋的機(jī)制。 也就是說(shuō)，fragment 里的 class 會(huì)在 host plugin 的 class 裝載之后而裝載。 只有 host plugin 里面沒(méi)有找到，才會(huì)去找 fragment 里面的類。

我們的framework，目前是由一個(gè)專門(mén)的小組在維護(hù)。其他小組是不能隨意改它的代碼的。 但是，當(dāng)有些情況下，使用這個(gè)framework的開(kāi)發(fā)小組需要修改這部分代碼，而這個(gè)修改 又只是局部的，只有這個(gè)小組需要用的，那么現(xiàn)在就很頭痛。后來(lái)用一種jar替換的方式 來(lái)滿足這個(gè)需要，但是搞得開(kāi)發(fā)起來(lái)很繁瑣，需要經(jīng)常的export。

一直以來(lái)也沒(méi)有去動(dòng) eclipse 的代碼，這次把應(yīng)用啟動(dòng)的模式從deploy改成launch 之后， 別的地方都好說(shuō)，唯有需要處理 fragment 的這個(gè)地方很頭痛。

如果把eclipse fragment的裝載順序調(diào)整一下，先裝載 fragment 里的class，再裝載 host plugin 里面的 class，這個(gè)問(wèn)題就迎刃而解了。framework開(kāi)發(fā)小組只需要處理 公用的代碼，使用 framework 的小組就可以用自己的 fragment 去處理特殊的代碼， 這個(gè)世界就清凈了。大家都可以用 launch 這種模式來(lái)啟動(dòng)應(yīng)用，加快應(yīng)用開(kāi)發(fā)的效率。

剛才改了一下，其實(shí)很簡(jiǎn)單，只是改 DefaultClassLoader 就行了，看一下代碼就知道該 怎么改。后悔怎么沒(méi)有早點(diǎn)改，呵呵。

主站： http://blogsite.3322.org/jspwiki/
目前來(lái)說(shuō)，最不喜歡的就是代碼生成這種機(jī)制。這個(gè)機(jī)制看起來(lái) 很快，能夠快速的開(kāi)發(fā)一個(gè)簡(jiǎn)單的應(yīng)用。不敢說(shuō)這是rails 的 核心，至少是它吸引人的一個(gè)優(yōu)勢(shì)，而正好是我所不喜歡的一點(diǎn)。

其實(shí)對(duì)于代碼生成這種機(jī)制，在 Pragmatic Programmer 里面 就已經(jīng)提到了，叫做 evil wizard。我很認(rèn)同那本書(shū)里面的說(shuō)法， 大部分的軟件開(kāi)發(fā)過(guò)程，是 修改 而不是 新建 代碼。也就
是說(shuō)， 真正好的代碼和框架，應(yīng)該有對(duì) change 支持比較好的機(jī)制。

ruby on rails 能夠根據(jù)model快速的生成代碼，確實(shí)有一些吸引力。 但是，一旦 model 發(fā)生變化，這時(shí)候代碼生成就不能起作用了，因?yàn)? 我重新生成代碼會(huì)把我修改過(guò)的代碼覆蓋掉。如果手工進(jìn)行編碼的話，我也 沒(méi)看出來(lái)它相當(dāng)于jsp的優(yōu)勢(shì)。當(dāng)然，它的 mvc 以及 helper 分離的 機(jī)制確實(shí)比純粹的 jsp 要好，不過(guò)對(duì)于代碼生成這一部分，我不覺(jué)得 是 rails 對(duì)我的吸引。

ror大概也考慮到這一點(diǎn)，所以也有對(duì) plugin 和 engine 的支持。 這兩個(gè)東西我現(xiàn)在還沒(méi)有研究，應(yīng)該會(huì)比較有意思吧。

主站：http://blogsite.3322.org/jspwiki/