grails 有一個 wicket 的插件：

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

我試了一下，發現最新版本(0.3)的wicket插件，運行helloworld都有問題，錯誤是：

wicket.markup.MarkupNotFoundException: Markup not found.

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

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

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

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

spring 與 osgi的第一個障礙

eclipse3.1, spring2.0.1，將spring.jar放到一個插件中，在另一個插件中去使用。 最簡單的例子，在context.getBean的時候就報了一個異常：

先是搜了一遍，沒有發現很有幫助的內容。然后跟了一下，發現還是因為xsd的映射找不到。而造成這個問題的原因， 是在 spring.jar當中的META-INF/spring.schemas 這個找不到。

而這個找不到的最根本原因，是因為在eclipse當中，META-INF目錄是不能夠被其他插件找到的。也就是說，META-INF 目錄是擁有spring.jar的那個插件所獨占的，而其他插件就算依賴于這個插件，也是無法找到META-INF目錄下的文件， 從而拋出這個異常。

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

這個問題解決之后，緊接著第二個問題就是

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

上面是我以前的一個經驗，今天仔細研究了一下，發現自己掉進了 經驗主義的圈套。

這個經驗是這樣積累起來的：在剛開始嘗試使用eclipse的時候，用的是3.0和3.1Mx系列，當時 不知道osgi是個什么東西 :$ 創建的幾個插件，都沒有創建osgi bundle manifest。也就是說， 只有plugin.xml，而沒有META-INF/MANIFEST.MF文件的。但是在運行期，eclipse會自動的 從plugin.xml當中讀取信息，生成臨時的MANIFEST.MF文件，放在 runtime的 configuration/org.eclipse.osgi/manifests 目錄下。而生成這個MANIFEST.MF文件，是 通過 PluginConverterImpl 這個類來實現的，在它的 isValidPackageName 方法中，所有的 META-INF或者以META-INF開頭的目錄，都不會被自動的export出去，從而在臨時生成的MANIFEST.MF 文件中，永遠不會有META-INF目錄的export。

當時剛開始接觸eclipse和osgi，根本不知道自己當時最佳的解決方案就是創建一個 bundle manifest， 然后在其中將META-INF目錄export出來。而是通過盲目的修改代碼來繞過這個彎。后來這個彎繞過去了， 留給我的經驗就是：META-INF這個目錄，是插件獨享的，別的插件不允許訪問的。

于是，在前幾天，當spring.jar當中的幾個META-INF目錄下的文件訪問不了時，我也認為這個經驗有用， 差點就去改eclipse的代碼了。幸好嘗試了一下，把spring.jar所在的插件中，將META-INF目錄共享出來， 居然就好了。仔細查了一下，發現屏蔽META-INF的代碼只出現在PluginConverterImpl這個類當中。 回頭想了想，終于明白自己這次是掉在經驗主義的坑里面了。

經驗主義害死人啊。唉。

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

SUN Tech 2006第一天

會場設在最擁堵的北四環中路，趕到會場已經接近9點，匆忙報道之后，
第一感覺是不像去年那么大的場面了，只有兩個會場，而且很奇怪的是，
參展的其他廠商，也只有AMD一家，顯得有點冷清。

James Gosling又一次出現了，不過做的演講并沒有很多新鮮的東西，值得
注意的倒是Ruby on Rails出現在他的演講內容當中，這大概也與JDK未來版本
要支持動態語言，以及SUN把jruby的兩個人招進去有一系列的關系。隨后有
一個SUN的技術展示，其中有意思的一個是 SPOT(Small Programmable Object Tech)，
有點象《少數派報告》當中阿湯哥用的手套，用手套來當做鼠標一樣的在
空中使用，很是不錯。

隨后一整天的演講，給我的感覺，重頭戲是Netbeans，其次是Ajax，再其次是
Java EE 5。感覺今天一系列的活動都與Netbeans有關，Ajax和Java EE 5包括
Java ME，都時不時的與Netbeans掛上鉤。從今天被Netbeans洗腦的結果來看，
Netbeans現在確實越來越好用，功能也越來越強大。Eclipse如果按照現在的發展
速度，確實有些危險。不過，從另一個角度看，有競爭才能促進發展，也不算是件
壞事。

其他方面的收獲，包括對JAVA SE 7 的一些特性了解，Java EE 5的一些介紹，以及
關于Java EE 5的參考實現 GlassFish的介紹，順便還聽了一些Java ME的東西，也
有些意思，可惜暫時用不上。

今天有一些感觸：
?
好的技術，如果沒有好的工具支持，也是很難生存的。這就聯想到我們自己的IMP框架，
過去將重點放在framework和engine上，而對于designer的投入則遠遠不夠。這樣造成的現
象就是限制了開發效率，從而沒有能夠最大的發揮IMP框架的作用。

Netbeans雖然好用，也能夠從一定程度上提高生產力。但是我還是那種觀點，看上去
很美的代碼生成機制，往往只是節省了“創建”的時間成本，而對于“修改”的效
率提高，卻不一定有幫助。

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

回家的時候，正趕上北四環的擁堵高峰，回到家已經很晚了，寫的很零亂，不知道明天
會不會有什么大的收獲。反正今天感覺就是被洗了一天的腦，害得我都想裝一個Netbeans
來玩玩了。

SUN Tech 2006第二天

又經歷了痛苦的2個小時到達了會場，今天的SUN公司主題居然是“開源的好處”，
重點提出開源最終有利于開源者，號稱SUN從OpenSaloris的開源當中獲得了很多
好處。不知道前幾年大家強烈要求SUN 開源的時候，是不是也是這種論調。也懶得
去查以前的新聞了，不過總算逐漸有將Java開源的打算了，而且SUN號稱要將所有的
軟件開源，這對于open source社區，也算是件好事。

今天總的來說內容不是很豐富，這一次的Tech Day，總共也就是幾個人在講，一個人
講好幾場，這在以前的Tech Day是很少出現的。

今天的收獲如下：

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

Apache Derby，也就是原來IBM收購informix時收購到的Cloudscape，現在又有了一個新
名字叫 Java DB，而且會隨著JDK6一起發布。Java DB的功能比較完善，據說性能也不
錯，號稱支持300G的數據量沒有問題。如果這樣的話，不僅hsql可以拋掉，而且說不定
mysql也可以不用了。我現在也很喜歡這種既可以embed，又可以做為cs的數據庫，現在
做rails的就是用sqlite，感覺也夠用了。Java DB還有個很強的功能是，可以將數據打包為
jar文件，做為只讀的db，放在光盤或者其他地方，做為備份和還原，以及做demo應用放
在光盤上，應該都有很大的用處。

JDK for script language. 在JDK6當中，已經支持 ruby和javascript兩種腳本語言了。
功能上感覺有點象BSF，但是由于隨著JDK6一起發布，所以以后影響力會更大。
而且，做演講的人也提到，jruby的開發者進入SUN公司，恐怕不只是用ScriptEngine
支持script語言這么簡單。今天體驗了一下印度人說英語，確實是強...

另外還聽了一下 MBean，Concurrence方面的東西，收獲也有一些。例如在JDK6當中，
MBeanServer缺省就啟動了，而不像JDK5里，需要用一個命令行參數才能啟動。
兩天下來，感覺這一期的SUN Tech Day和以往最大的區別就是，這一期完全是被
SUN自己壟斷了，沒有別的公司演講， 不討論別的公司的內容，沒有別的公司參展。
言必稱 NetBeans，操作系統必稱 Solaris。從一個角度來看，SUN公司確實 積極的
參與到了開源社區當中，并且比以前更加接近用戶，也更積極的響應用戶的request。
這一點，從Netbeans的進展神速， 到JDK最近幾個版本的新特性增加速度，都比JDK5
以前要好很多。這對于Java的進一步發展，可以說是一件好事。從另一個 角度來看，
這一屆Tech Day表現出來的情況，不知道是應該說SUN更加有了自主意識，還是應該說
SUN確實沒有很好的組織 這次會議。從參加演講的人員，到展廳的布置來看，
都不如往屆。不知道是不是SUN財務緊張造成的，hoho.

又花了兩個小時才從首堵北京的北四環中路到了家，感覺今年的Tech Day，
最大的收獲是被洗腦了，也體會到了目前最火爆的Ajax是如何的火爆。

主站: http://blogsite.3322.org/jspwiki/ 代碼的衛生、習慣及其它...

最近忙，發現家里開始臟亂差了。仔細想想，其實之所以會這樣，
是因為經常發現有點臟的地方，也懶得動，總是想等到啥時候大掃除
一下子全部清理干凈。后來地面越來越臟，就越來越不注意，進入了
一個惡性循環。

不禁聯想到“破窗戶”理論，有個破窗戶的社區，會逐漸變得不適合居住。
又想到一個經常看到的現象，如果一個電線桿下有一包垃圾，只要清理
不及時，過段時間，這個電線桿就會變成一個垃圾堆。

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

那么，要避免這種無意義的重復勞動，一方面是程序員本身意識的糾正。打掃
一個舊房子，雖然臟一點，但是通常比新建一個房子還是要快和省力。另一個
方面，程序員應該有這樣的信念，不能讓自己的代碼變成垃圾堆。也就是說，
不能容忍自己的代碼中堆滿垃圾。

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

當然，如果判別某段代碼是不是垃圾，或者及時發現第一段垃圾代碼，那就是
另一個話題，例如用ut，用code review，等等。《Working Effectively with Legacy Code》
這本書里面，提到了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.

有人會覺得我管的太細，不揪架構、設計，反而去管代碼，只見樹木不見森林。我個人
的看法，架構、設計再好，都需要代碼來進行實現。如果這個基礎沒打好，以后這個
代碼總是會變成無人想碰的垃圾堆。

當然，我也反對無意義的追求完美。我不是個有潔癖的人，所以，代碼到什么程度就算是
干凈的了？我個人的看法是，Clean code that works。當然這一點其實不容易達到，但是
做為一個程序員，我還是努力去追求這一點的。

主站： http://blogsite.3322.org/jspwiki/
在上次的文章當中，把 eclipse做為web framework的核心，并且使得 servlet 的定義和mapping做為擴展點，確實狠 方便。不過現在又面臨一個問題，有個歷史遺留系統當中，有jsp 的應用。而jsp與servlet 的一個 很大的區別在于，它需要用 javac 去做編譯。這就使得問題復雜化了，特別是使得 class loader 的關系變得更復雜。

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

這里不僅class loader 眾多，而且關系復雜。一不小心就容易拋出 class not found 異常，或者是 class cast 異常。相對而言，只支持servlet 就狠簡單，因為只要把 servlet 的 context class loader 用 eclipse bundler loader 替換掉就行。而jsp的編譯機制，導致了問題的出現。

我對于這種復雜classloader情況的心得，就是把錯綜復雜的 class loader 關系網拉直，變成一棵 樹。這樣的好處就是，對于loader 的關系比較清晰，出現ClassNotFoundException和 ClassCastException這兩種情況的時候，都狠容易判斷怎么回事，不會被繞暈。這種時候，單步跟蹤 只是找死，把classloader關系畫出來，有利于對問題的分析。

于是畫了這樣一個圖，把復雜的網拉直了，問題就迎刃而解了。

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

不過這樣其實還是有個問題，如果要在 jsp 當中調用某個插件當中的 class，那么在編譯期就會出現 問題。不過由于目前只是解決 legacy jsp 應用的問題，所以這個暫時不存在。我能想到的解決方案 其實也狠簡單，把這些 jar 文件的url也做為擴展點出現，那么當jsp需要某個class時，只要把它 所需要的 jar 文件的 url 做為一個擴展，在 LauncherClassLoader 當中將這些jar文件添加到 url loader 當中，而這些 url 會出現在 jsp 的編譯class path當中。

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

一直以來，eclipse 對于 fragment 的概念都是一種補充，而不是覆蓋的機制。 也就是說，fragment 里的 class 會在 host plugin 的 class 裝載之后而裝載。 只有 host plugin 里面沒有找到，才會去找 fragment 里面的類。

我們的framework，目前是由一個專門的小組在維護。其他小組是不能隨意改它的代碼的。 但是，當有些情況下，使用這個framework的開發小組需要修改這部分代碼，而這個修改 又只是局部的，只有這個小組需要用的，那么現在就很頭痛。后來用一種jar替換的方式 來滿足這個需要，但是搞得開發起來很繁瑣，需要經常的export。

一直以來也沒有去動 eclipse 的代碼，這次把應用啟動的模式從deploy改成launch 之后， 別的地方都好說，唯有需要處理 fragment 的這個地方很頭痛。

如果把eclipse fragment的裝載順序調整一下，先裝載 fragment 里的class，再裝載 host plugin 里面的 class，這個問題就迎刃而解了。framework開發小組只需要處理 公用的代碼，使用 framework 的小組就可以用自己的 fragment 去處理特殊的代碼， 這個世界就清凈了。大家都可以用 launch 這種模式來啟動應用，加快應用開發的效率。

剛才改了一下，其實很簡單，只是改 DefaultClassLoader 就行了，看一下代碼就知道該 怎么改。后悔怎么沒有早點改，呵呵。

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