stone2083

@penngo
收到，有空的時候，我去學(xué)習(xí)下jsoup。

@問題
每種語言都是自身的特點（優(yōu)勢和弊端），以及背后的設(shè)計理念。我們要用合適的技術(shù)解決對應(yīng)的需求，使用正確的思想去使用該技術(shù)。
（在我周圍遇到有太多的同學(xué)，面對10來個頁面的需求，也要使用java，還要使用mvc，orm framework，三，四層架構(gòu)，之后再來抱怨java的復(fù)雜。）
這促使我站在自己的理解上，總結(jié)了三門具有代表性的語言特點和其適用的場景（還少一種函數(shù)式編程語言）。

之所以發(fā)到blog：
1.在目前能力范圍下，總結(jié)對這些事物的理解
2.找到志同道合的人員，可以一起交流

就事論事的討論，才能讓你，我，彼此都得到成長;
沒有任何理論說明的，純屬發(fā)自內(nèi)心的主觀性批判語言，相信對我的幫助幾乎沒有。

不妨說說沒有毛用的理由，這有助我們進(jìn)一步討論。

@pyzhu
得到同事指點,還有一種更好的方法:
system.setProperty(DebuggingClassWriter.DEBUG_LOCATION_PROPERTY, "指定輸出目錄");　

詳見:http://www.javaeye.com/topic/799827

@wuzhengju
唉，我這個土人。。。
之前思維一直停留在如何破解驗證碼上了。直到寫完這個東東，在寫腳本的時候：
curl -A "$AGENT" -e $TRAFFIC_URL -b "ASP.NET_SessionId=$SESSION_ID;isLoginedWeb=T;ImageV=$code" -d "$QUERY_PARAM" "$TRAFFIC_URL" -o $TMP_CONTENT_BASE
才發(fā)現(xiàn)在cookie中已經(jīng)存在這個ImageV了。
不過為時已晚，米已城粥。。。 ：）
================================================
好久不見了，最近工作還順利嗎？

@阿風(fēng)
其實是周末下午沒事情干，弄著玩的。
之前沒有涉及過圖片相關(guān)的，趁機(jī)也稍微學(xué)習(xí)下。 ：）

@pyzhu
修改源碼也是一種方法 ：）
我是在debug的時候，Variables窗體中，編寫java代碼，拿到class變量信息做自己的處理

@pyzhu
用了比較猥瑣的辦法,
debug,將動態(tài)生成class的字節(jié)碼 輸入到文件中,然后反編譯得到的.

@Unmi
我上面的例子,僅僅是想說明反射調(diào)用方法的開銷(不局限在get/set上).
如果是對java bean getters/setters的操作,可以考慮使用cglib的BulkBean類.
cglib下的fastclass和fastmethod,確實有一定的優(yōu)勢,但是優(yōu)先并不明顯(在jdk1.6上)

@王衛(wèi)華
你是指spring aop中cglib proxy的實現(xiàn)?

@kylin
明白你們這邊的情況了.

Service層的測試相對還是容易的,我們這邊也有一套測試框架(類似DDSteps,也是對一些業(yè)界測試工具的整合加改進(jìn)).并且對Service依賴的外部環(huán)境,都做了隔離,主要包括:
1.Mock Dao impl
2.Mock Core Service impl (外部核心業(yè)務(wù)服務(wù))
3.Mock Search Engine impl
4.Mock Cach impl
....
測試重心,主要集中在Service內(nèi)部邏輯的測試上.
而公司使用的測試框架很好的支持了這些需求.


難點還在DAO的測試上.
數(shù)據(jù)準(zhǔn)備的復(fù)雜度,取決于表設(shè)計的復(fù)雜度和sql的復(fù)雜度.尤其在ibatis支持dynamic語句下,要準(zhǔn)備覆蓋測試sql語句的數(shù)據(jù).挺繁瑣的.
這并不是說使用excel,還是wiki等的問題.而是數(shù)據(jù)內(nèi)容的準(zhǔn)備上.

每個測試數(shù)據(jù)的準(zhǔn)備,都是為了一個特定的testcase設(shè)計目的的.而當(dāng)字段多,并且表設(shè)計相對復(fù)雜的時候,這個準(zhǔn)備意圖,挺難被傳承下去的.
隨著項目,小需求的進(jìn)行,我們這邊,差不多幾十人,都有可能修改同一個sql代碼 :(

@啊寶
控制流程用Exception(try..catch)也好,還是ResultModel(if..else)也罷.只是不同的設(shè)計理念而已.
都可以,都對

至于提到異常煩,如果是為性能問題.我以為大可不必.
1.異常的性能沒那么差.在上面的測試中,一個異常的產(chǎn)生,0.02ms而已
2.大多數(shù)的應(yīng)用,對性能要求并非很高
3.引起性能瓶頸的,往往是不合理的設(shè)計,錯誤的使用同步等業(yè)務(wù)代碼產(chǎn)生的.
4.實在不行,就是用改進(jìn)后的異常

如果再不行,那么只好拋棄業(yè)務(wù)異常吧
如果再不行,那么只好拋棄java改用c等語言吧.

選擇一種語言也好,選擇一種設(shè)計也罷,只是為了更好的處理需求而已.

至于上文,只是為了描述異常的本質(zhì).在了解原理的基礎(chǔ)上,讓業(yè)務(wù)異常的使用不出現(xiàn)性能的浪費而已.
絕不是表明,異常性能真得對系統(tǒng)產(chǎn)生了影響 :)

提供這個思路,并不是說替代之前的方案,更不是對傳統(tǒng)測試方案的否定. 僅僅是為了多一種選擇.

@藍(lán)劍
DAO業(yè)務(wù)邏輯不復(fù)雜只指:在DAO方法中,不會有復(fù)雜的分支流程,往往只會調(diào)用一條SqlID執(zhí)行sql.但是這不意味sql不復(fù)雜.
打個比方,報表的生成,業(yè)務(wù)邏輯非常簡單(根據(jù)什么樣的條件,能看到什么樣的數(shù)據(jù)),但是sql絕對的復(fù)雜. :)
dao方法,也只會有一句 getSqlMapClientTemplate.queryForList("....",param); // 簡單吧 :)

數(shù)據(jù)準(zhǔn)備的工作量低嗎?維護(hù)成本低嗎?至少在我實踐的項目中,沒有像sample那樣低(dbfit,dbunit,dbutil等sample,都是單表的說明,單表字段往往少于5個字段). 實際情況是:
1.字段多
2.表關(guān)聯(lián) (尤其在tree結(jié)構(gòu)的表,父節(jié)點的依賴,光是這樣的準(zhǔn)備,都非常容易寫錯)
3.對于查詢的語句(尤其是分頁),需要根據(jù)動態(tài)條件,準(zhǔn)備好需要的數(shù)據(jù)
4.數(shù)據(jù)準(zhǔn)備意圖需要被傳承
在我看來,并且實踐過來,挺不容易的.

sql的assert,只要根據(jù)條件參數(shù)的不同,做不同預(yù)計sql的assert,成本絕對比結(jié)果數(shù)據(jù)校驗,來得低.

至于最后一點.
是用ibatis,還是jdbc;不是單元測試成本(方案)決定的;而是需求,應(yīng)用,架構(gòu)設(shè)計,部門崗位情況等決定的.
我們有專業(yè)的dba,對所有sql要做review,總不能給一堆jdbc的文件給他們吧.ibatis就挺好了.
再說了,對于ibatis下dao編碼,錯誤率是sql寫錯的高呢?還是row mapper錯誤高呢?所以如果因為這點,來否決全部,挺不公平的.

@sgz
大多數(shù)時候,想法是被現(xiàn)實逼出來的 :)
在我們這邊,dao幾乎沒有復(fù)雜的業(yè)務(wù)邏輯,僅僅是對SqlMapClientTemplate的使用而已.
但是在針對DB的單元測試時,代價又是如此的巨大(主要還是在數(shù)據(jù)準(zhǔn)備上).
成本,收益比,不劃算,開發(fā)們抱怨多.

分析現(xiàn)狀和開發(fā)們實際需求(寫dao,主要是擔(dān)心sql寫錯)后,才萌生了這個想法.

@kylin
簡單地看了下ddsteps,它是一套集成測試工具.主要包括:
dbunit,selenium,mock web(http) server,easymock和spring.
它對DB的支持,也是采用傳統(tǒng)的方式.(沒猜錯的話,是使用了,最多封裝了dbunit)
并不能解決我現(xiàn)在遇到的問題:
1.背負(fù)數(shù)據(jù)庫環(huán)境
2.準(zhǔn)備測試數(shù)據(jù)
3.準(zhǔn)備預(yù)計結(jié)果數(shù)據(jù)
這些麻煩的工作量.

而且在公司中,也已經(jīng)有一套測試框架,我們要做的,并不是選擇框架(替換框架),而是選擇一種合適敏捷單元測試的思路和方案. 讓框架支持敏捷的方案而已.

突然記起來了.請參考這篇文章:
http://sdh5724.javaeye.com/blog/619130

在自己電腦上,一直無法重現(xiàn)這個問題(無論加大循環(huán),或者增加線程數(shù)),明天回公司再去看看.

"Thread-1" prio=6 tid=0x00c70bd8 nid=0x914 runnable
兩個線程都是runnable狀態(tài).

這程序,理論上,不應(yīng)該出現(xiàn)死鎖的.

@BearRui(AK-47)
Sorry,Sorry.
你底下的幾個button做的不錯,發(fā)覺挺有意思的,就多點了幾下.沒想到居然是發(fā)評論用的. :)

@TestThug
1.要看公司政策了;
2.要看JTester作者意愿了;

從目前看,開源的可能并不大 :(

今天又細(xì)看了代碼,發(fā)現(xiàn)覆寫
AbstractXmlApplicationContext.initBeanDefinitionReader(XmlBeanDefinitionReader beanDefinitionReader) 方法更為合理.

@周
理論上說,源上肯定存在著兩個package的.是否是你自己設(shè)置了其他源導(dǎo)致的?

不過沒關(guān)系,手工下載包,再安裝好了.
http://packages.ubuntu.com/
找到你ubuntu版本,點擊所有產(chǎn)品包(例如:http://packages.ubuntu.com/lucid/allpackages),查找pppoe和pppoeconf.手工下載,安裝即可.

當(dāng)然,ubuntu cd自帶也有.插入ubuntu cd.使用apt安裝也可.

有一份詳細(xì)的文檔,不妨看看:https://help.ubuntu.com/community/ADSLPPPoE

@小菜花
理論上來說,傳遞jsessionid,只要value是一致的,服務(wù)端不會創(chuàng)建多份session.
可以在測試環(huán)境下通過debug 或者 監(jiān)控工具,跟蹤下創(chuàng)建多份session的情況.

@BeanSoft
接受觀點.
之所以考慮使用毫秒,是因為不同的開發(fā)機(jī)性能參差不齊,對性能的影響遠(yuǎn)遠(yuǎn)大于本身計算的精確性.
而這個簡易工具,本意只是提供感性的性能數(shù)據(jù).所以提供的數(shù)據(jù)并不精確(當(dāng)然,之后會隨著項目開發(fā)中提出的需求做完善),而是相對于程序員更友好的單位.

為什么不考慮使用JSESSIONID,來模擬更真實的用戶并發(fā)情況?

@出錯
比較遺憾.我第一時間和支付寶工程師聯(lián)系反饋了這個問題.沒想到他們到現(xiàn)在還沒有跟進(jìn)...

@小菜花
準(zhǔn)確地講,除非你的應(yīng)用完全不需要保存狀態(tài)(無狀態(tài)應(yīng)用),不然地話,只要有一個新的連接過來,web容器都需要創(chuàng)建Session概念,維護(hù)狀態(tài)信息.
但是Session是什么?Session僅僅是一個概念:"Provides a way to identify a user across more than one page request or visit to a Web site and to store information about that user."--簡單地講,保存用戶狀態(tài)信息.
所以說,我們完全可以根據(jù)應(yīng)用的需求,定制Session的實現(xiàn):
a. Session保存到JVM內(nèi)容中--Tomcat默認(rèn)的實現(xiàn)
b. Session保存到Cookie中--Cookie-Based Session
c. Session保存到本地文件--Tomcat提供的非默認(rèn)實現(xiàn)之一
d. Session保存到Cache Store中--比如常見的Memcached
e. Session保存到數(shù)據(jù)庫中--比如保存到mysql數(shù)據(jù)庫session表,中間對于活躍的Session 緩存到cached中.
......
那么,假如一個應(yīng)用有大量一次性不同用戶的請求(僅僅是一次性的,比如上述文章描述的場景),那么選擇c,d,e方案都能有效解決文中所描述的問題.

"業(yè)務(wù)比技術(shù)重要“看怎么去理解了，要理解業(yè)務(wù)的邊界；技術(shù)的邊界
我雖然比較看重技術(shù)，但是也認(rèn)可”業(yè)務(wù)比技術(shù)重要“。
我所理解這句話的含義：業(yè)務(wù)是本，技術(shù)為業(yè)務(wù)服務(wù)。

問題是什么？
業(yè)務(wù)包含哪些范圍（邊界），我認(rèn)為的業(yè)務(wù)，不僅僅是原始需求，包括：
＊原始業(yè)務(wù)需求
＊需求分析
＊業(yè)務(wù)建模
這些都屬于業(yè)務(wù)規(guī)劃（或者是產(chǎn)品規(guī)劃）的一部分。

技術(shù)包含哪些范圍（邊界），我認(rèn)為：
＊選用技術(shù)語言
＊技術(shù)架構(gòu)
＊實現(xiàn)模型
＊實現(xiàn)編碼

只是現(xiàn)在，很多需求分析，業(yè)務(wù)建模（或者說領(lǐng)域建模）都是技術(shù)團(tuán)隊在做，會誤以為這些都是屬于技術(shù)的范圍。
真正能做好業(yè)務(wù)規(guī)劃的團(tuán)隊和單位，真的是太少了，往往只提供原始需求，就讓技術(shù)去實現(xiàn)罷了。

@名揚/六耶子
cglib底層依賴了asm，它主要是在“動態(tài)代理”場景下增加易用性。
如果要動態(tài)生成字段，方法，那么asm或者javassist這兩個技術(shù)，更合適你。

剛?cè)truts官方網(wǎng)站溜達(dá)了下：
http://issues.apache.org/struts/browse/WW-3024

已經(jīng)有人提交了bug，在struts2.1.8中，修復(fù)。

查看了xwork trunk的代碼，發(fā)現(xiàn)修復(fù)方式，跟我原文的一樣。先這么用一段時間吧。 ：）

trunk代碼：
http://svn.opensymphony.com/svn/xwork/trunk/core/src/main/java/com/opensymphony/xwork2/validator/AnnotationActionValidatorManager.java

@Simon
沒有放之四海而皆準(zhǔn)的技術(shù)，任何技術(shù)，總是有利弊的，關(guān)鍵是看怎么權(quán)衡了。
用通配符也好，zero config plugin也好，都可以，我只有一個要求，就是COC。
做為程序員，封裝變化，抽取共性，減少一切可以減少的重復(fù)勞動力。

在我看來，一個一個配置action，就是重復(fù)勞動力。至少在80％的場景下，配置都是差不多的。
試想一下，當(dāng)一個應(yīng)用，有上千個action時，光是action的配置文件，就是幾千甚至上萬行。這個維護(hù)工作量，不敢想象。

至于攔截器，同理，我以為，80％的情況下，action配置的攔截器都是同樣的。所以就算使用通配符，我可以用其他的方案解決特殊(20%)的需求。

Annotation，額，這個玩意，我不敢濫用。只有20％的需求才有的特殊需求場景下，我還會考慮（僅僅是考慮）使用Annotation。
Struts2中，Action上的annotation設(shè)計，我一直不敢恭維。所以我絕對不會使用annotation的。
其實從我原文中，一直在描述如何尋找Validatior文件的方法，沒有說我用了annotaion。在很多場景下，我一直是xml的擁護(hù)者，當(dāng)然最擁護(hù)的，是Convertion。 ：）

@梁章坪
沒錯，最正宗的格式是ActionName--validation.xml。
請看，AnnotationActionValidatorManager中的buildValidatorConfigs方法片段：
validatorConfigs.addAll(buildClassValidatorConfigs(clazz, checkFile));
在buildClassValidatorConfigs方法中，
String fileName = aClass.getName().replace('.', '/') + VALIDATION_CONFIG_SUFFIX;
就是你說的ActionName--validation.xml格式。
在一個Action只有一個方法（execute）的時候，這樣是夠用的。

但是Struts2為了支持一個Action有多個方法（CRUD）的時候，那么怎么為不同的方法尋找它需要的校驗文件呢？
于是乎，繼續(xù)看AnnotationActionValidatorManager中的buildValidatorConfigs方法片段：
if (context != null) {
validatorConfigs.addAll(buildAliasValidatorConfigs(clazz, context, checkFile));
}
將Action名和context做組合，作為校驗文件的別名（alias）。

至于context是什么？我一開始以為是method名，結(jié)果看了代碼，發(fā)現(xiàn)不是。struts2是傳了${配置中的action name=""}中的名字
看來它的本意是希望同一個action的方法，在不同使用場景下，也允許不同的校驗規(guī)則。

所以就有了這樣的格式定義。 ：）

其實本身并沒有非常強(qiáng)制的標(biāo)準(zhǔn)，比如一定得：3<參數(shù)<類 用map
原則只有一個，方便客戶端的調(diào)用。

比如上面舉的例子，一共有19個參數(shù)，調(diào)用者能方便的調(diào)用嗎？哪個參數(shù)在哪個位置，能方便找到嗎？

所以，自定義map（定義了key常量的map）或者parameter Class，更合適上面的場景。

@林茂
能兼容outlook的事件邀請。至于是否100％，不敢保證，從我使用情況看，outlook 2003,2007的事件邀請，都能兼容。
但是不兼容發(fā)送的實踐邀請，我使用lightning發(fā)送的邀請，在outlook上查看，只能顯示一堆源碼。

個人不希望僅僅因為猥瑣解決這個bug，而引入對spring-web的依賴。
手寫一個CharacterEncodingFilter也是比較方便的事情。

當(dāng)然，切會org.apache.struts2.dispatcher.FilterDispatcher，也是一個可選方案。
當(dāng)時自己不選擇FilterDispatcher的原因是：
在應(yīng)用測試的時候，順帶測試struts2 StrutsPrepareAndExecuteFilter（官方推薦）方案.免得等2.1.7發(fā)布后，在換回StrutsPrepareAndExecuteFilter時，又發(fā)現(xiàn)其他問題。
相對來說，刪除一個Filter的風(fēng)險更小一些 ：）

url參數(shù)中帶中文的應(yīng)用場景還是很多的。
關(guān)鍵是采用某種技術(shù)手段去實現(xiàn)的問題了。
url encoder就是用來做這樣的事情的：
java.net.URLEncoder.encode(urlParams, encoding);

比喻很形象，也比較能說明問題。站在技術(shù)角度上，我非常認(rèn)同你說的觀點。
對于一家長期發(fā)展的公司，系統(tǒng)演變會越來越復(fù)雜，前期為了貪圖方便的設(shè)計，總有一天，會帶來無窮的痛楚。這些俺都明白。目前也在經(jīng)歷這些痛楚。

但是，確實也存在很多系統(tǒng)，本身業(yè)務(wù)并不復(fù)雜（比如外包公司接手的一次性的小項目），并且也很難看到未來的發(fā)展方向（比如針對一些創(chuàng)業(yè)型公司的項目），之后重寫＋數(shù)據(jù)遷移的方案代價遠(yuǎn)遠(yuǎn)小于系統(tǒng)重構(gòu)的代價，那么我，決不會采用復(fù)雜的架構(gòu)，把簡單問題復(fù)雜化。
PHP，ROR（使用action＋model，沒有過多分層）的項目，在中小型項目中，比較流行的，也能說明一些問題。

很多的系統(tǒng)，如果能標(biāo)標(biāo)準(zhǔn)準(zhǔn)按照action->biz->dao的結(jié)構(gòu)寫，已經(jīng)是相當(dāng)不錯了（通過一些應(yīng)用拋出的錯誤異?？?，很多甚至在jsp上書寫大量的業(yè)務(wù)邏輯，或者在action屬性大量的業(yè)務(wù)邏輯）。要在biz層抽象出biz->service的概念的系統(tǒng)，并不是太多。（至少是中型公司及以上，才需要考慮的）

我說這些，不是為了否決樓上的說辭－－其實我是非常認(rèn)同的觀點。
我只是想表明，任何的架構(gòu)設(shè)計，都是需要根據(jù)需求以及未來的發(fā)展，來決定的。

一般應(yīng)用中，biz層和service層的概念就是同一個，硬做分層，是脫了褲子放屁 ，自找麻煩。 ：）

當(dāng)公司規(guī)模大了，應(yīng)用龐大了，復(fù)雜了：
比如，當(dāng)web應(yīng)用有幾十，上百個；task應(yīng)用幾十，上百個。。。
該如何控制和維護(hù)業(yè)務(wù)人員編寫的biz和dao呢？

于是乎，就需要抽象出service層（核心組件服務(wù)／核心產(chǎn)品服務(wù)），service依賴dao api，search engine api，dw api等等，并且通過某些協(xié)議，暴露自己的service api

前臺應(yīng)用（web應(yīng)用，task應(yīng)用等），通過biz層，調(diào)用不同service api（不再涉及dao等底層服務(wù)）

如此一來，底層實現(xiàn)發(fā)生變化，比如數(shù)據(jù)庫重構(gòu)等，只要維持service api不變，不會涉及前臺應(yīng)用的變動。

如同上面說的，要不要biz，service，還是根據(jù)應(yīng)用規(guī)模來決定的。

根據(jù)需求來決定的。
系統(tǒng)分層，和公司設(shè)立部門的概念是同樣的。

一個創(chuàng)業(yè)型公司，很可能整個公司就一個人：即是老板，又是程序員，同時還是業(yè)務(wù)員，等等，
如同一個系統(tǒng)中，一個action做了所有的業(yè)務(wù)；

一個中型公司，有一個老板，有一個技術(shù)人員，有一個業(yè)務(wù)人員，有一個運營人員，等等，
如同一個系統(tǒng)中，有action層，biz層，service層，dao層等，通過jar包依賴調(diào)用；

一個大型公司，有CEO，有技術(shù)部們，有業(yè)務(wù)部門，有運營部門，等等，
如同系統(tǒng)模型中，每個模塊存在獨立service系統(tǒng)服務(wù)，依賴dao api,依賴search engine api,依賴DW api等；
前臺又有不同的業(yè)務(wù)系統(tǒng)，有自己的action，依賴biz層，biz層又依賴獨立模塊的service api；
系統(tǒng)之間的依賴，采用SOA架構(gòu)等

不同的企業(yè)規(guī)模，決定不同的公司組織架構(gòu)；
不同的產(chǎn)品需求，決定不同的系統(tǒng)架構(gòu)；

多謝指點。細(xì)節(jié)部分，確實沒有仔細(xì)思考過。
平時忙于項目，太少有空余時間，來思考這些技術(shù)性問題。 ：（

我還有一個問題不明白：
如果需要捆綁Object，類似RPC調(diào)用，那為什么不選擇hessian等二進(jìn)制序列化方式的組件。
畢竟二進(jìn)制序列化／反序列化效率比xml轉(zhuǎn)化高多了。

當(dāng)然hessian不同版本在協(xié)議上的不兼容，是一件很頭疼的事情 ：（

第二次看到SLF4J的介紹了。有了感性的認(rèn)識。不免有些心動。等有空閑的時候，深入了解下這東東。

心態(tài)要擺正，如果純粹為了面試而去看面試題，是沒多少意義的。
真正在面試過程中，對于一些僅僅看過面試題卻沒有深入掌握的人，只要多問幾個為什么，往往就回答不上來了。

其實這玩意，也是臨時之作，有很多不完善的地方。
主要是提供一個思路，供大家一起討論。

@叱咤紅人
我不太明白，在遠(yuǎn)程通信上，使用xml作為中間傳輸內(nèi)容，就是為了做系統(tǒng)（甚至是異構(gòu)系統(tǒng)）之間的解耦。
如果xml內(nèi)容上，還捆綁了類信息，那么既要求兩個系統(tǒng)為同語言系統(tǒng)，又將兩個系統(tǒng)都捆綁到具體的一個model上。未必是一件好事。

不推薦使用tomcat默認(rèn)的session機(jī)制。
基于內(nèi)存的session，無可避免GC帶來的問題，何況在集群環(huán)境下，同步開銷太大。
推薦使用基于memcached，或者database的session。

這套桌面主題看上去不錯 ：）

一直在用，性價比超高的一款工具。

想法是好的，做法是不可取的。
任何對第三方組件的擴(kuò)展，需要遵循開放－封閉原則：只能尋找組件的擴(kuò)展點進(jìn)行功能擴(kuò)展，不允許直接修改源碼。

試想一下，你修改了源代碼，以后如何解決與官方網(wǎng)站版本升級的同步問題？
沒有團(tuán)隊敢使用你的包。

很早之間，我就有這個想法。但是發(fā)覺MappedStatement,SqlMapExecutorDelegate都是面向?qū)崿F(xiàn)編程；
并且SqlMapClient也是通過：
public SqlMapConfiguration() {
errorContext = new ErrorContext();
delegate = new SqlMapExecutorDelegate();
typeHandlerFactory = delegate.getTypeHandlerFactory();
client = new SqlMapClientImpl(delegate);
registerDefaultTypeAliases();
}
直接new出來的。
所以，似乎找不到擴(kuò)展的地方來實現(xiàn)“分頁”的需求。

不知道大家是否有更好的方案，歡迎討論。

現(xiàn)在，對spring是越來越難下定義了。
通過mvnrepository看看spring的范圍：
http://mvnrepository.com/search.html?query=spring
做的是越來越龐大了。

想想早幾年的時候，對Spring的概念，還停留在ioc容器上。接下來又出現(xiàn)了AOP的概念。
如今呢？感覺spring對任何第三方組件，都要插一手。不過，話又說回來，spring對第三方組件的封裝，確實提高了開發(fā)效率。

關(guān)鍵看，你要用spring什么了？

推薦使用cglib的beancopier替代beanutil做copy工作。