摘要: 在JSF和Richfaces的官方示例里面沒發現正經的數據庫分頁示例，于是自己輪了一個，還算比較滿意，分享出來。

struts等框架，視圖（jsp、freemarker等)直接獲取action中準備好的數據結果集合，請求下一頁數據的時候，同樣后臺action處理請求，把action中的數據集合用新的這一頁數據替換掉，然后渲染頁面，從而實現分頁。每次請求action的處理過程可以拿到頁號等信息，所以在action調用service的時候就可以使用這些信息，調用相應的方法做分頁數據查詢。

JSF結合Richfaces做這個事情和Struts等框架有有很大的區別。
  閱讀全文

寫寫過去兩年我們做的一些事情。有興趣參與的兄弟（北京）可以聯系我。

在前面的一片日志里面已經大概說過，關于建立功能級別的組件的想法。這些想法最初在我來到我到現在所在的這家公司之前就有，進入這家公司之后有了一個合適的機會，所以就開始做起來。后來起了個名字叫做Onion，取意于“一片一片相似的結構，最終正和起來形成一個功能整體”。最早的時候曾經想過叫做StoneBridge，最終因為和“四通橋”太接近而作罷（公司在四通橋）。

Onion的目標是為企業應用開發團隊提供兩個方面的幫助：

    6. 優異的交流溝通能力和文檔寫作能力
    7. 有處理大數據經驗者優先

qupier.com發給用戶的郵件目前有以下幾種：

    1.賬號激活
    2.密碼找回
    3.搖號中簽與否的通知
    4.未開通任何服務的提醒

結果發給QQ郵箱的信件被退回很多。都是類似如下理由：

     摘要: 做去皮兒網（http://www.qupier.com），內容管理是一個系統，前端網站是一個系統，這兩個系統之間獨立部署，但是緩存要能夠互通。例如后臺修改了某個消息類型的說明，在前段網站上要能夠展現出來（使用了hibernate的查詢緩存）。其他的一些場景也許要緩存，例如網站的shiro權限信息緩存，不過這個不需要和后端系統互通。但是既然開搞，也不好意思再掛著ehcache。于是一并升級。

前面一篇日志各種碰壁后，終于找到了理論上能夠實現功能的兩個產品：gemfire和hazelcast。于是，開始嘗試。  閱讀全文

依然，先發廣告：去皮兒網（http://www.qupier.com），每月26日通知你是否中簽。已經推出廣州的搖號結果通知了。

之前做業務系統，緩存用的是ehcache，集群的時候用multicast廣播通知。隨著節點的增多，希望把整個緩存切換到集中式緩存上來。折騰了兩天，各種碰壁。

首先是需求：
    1.Hibernate的二級緩存
    2.獨立的業務緩存
    3.支持region，支持keySet，containsKey，region內遍歷

首先看了大名鼎鼎的memcached，以及客戶端spymemcached。失敗。首先，不支持region，各種輪子都是在key上加前綴之類的做文章。不支持keySet，不支持containsKey，不支持遍歷。于是Pass。

然后看到了ehcache server，可惜人家似乎發展商業版本的torrxxxx去了，ehcache server也2年多沒有更新，并且沒有hibernate二級緩存結合的任何文檔、網文。Pass。

然后看到了Infinispan，據說是jboss cache 的后繼。也看到了hibernate-infinispan，也支持分區，心里一陣高興。使用RemoteCacheStore可以實現hibernate的二級緩存以及查詢緩存使用遠端的緩存服務器。深入嘗試，結果發現，首先，一定要jta，太不平民化了。其次，hibernate-infinispan里面明確寫了只支持read-only,non-restrict-read-write,transactional這三種緩存策略。但是我的已有代碼中有很多事read-write的。于是失敗了。

最后看到了redis，以及jedis。當前火爆的nosql數據庫。想來也可以實現我要的功能。根據網文，可以使用hashes的方式實現region。這個方面基本上符合要求。然后很高興在github上也找到了hibernate-redis這個項目，仔細一看，只支持read-only,non-restrict-read-write這兩種緩存策略。郁悶死了。后來同樣在github上看到一個jedis-lock項目，做了redis的鎖機制。開始嘗試修改hibernate-redis，依賴jedis-lock，想做個read-write策略出來，結果發現自己對hibernate的cache部分還是不太熟悉，里面各種softLock之類的東西，看ehcache的代碼就看頭大了。郁悶。

總結，如果你用jta，不用read-write，那么用hibernate-infinispan就好了。否則，，，就麻煩了。

     摘要: 照例先做廣告：去皮兒網（http://www.qupier.com），每月26日通知你是否中簽。很快要退出廣州的搖號結果通知了。

Seam的Events用的很舒服，spring提供的事件機制太羅嗦，所以起了念頭，著這思路移植一下。最終效果如下：

//發布事件
Events.instance().fire(eventName,arg1,arg2.);

//發布異步事件
Events.instance().fireAsynchronous(eventName,arg1,arg2.);

//在事務中，發布當事務成功commit時觸發的事件
Events.instance().fireOnTransactionSuccess(eventName,arg1,arg2.);

//在事務中，發布當事務完成（commit/rollback）時觸發的事件
Events.instance().fireOnTransactionCompletion(eventName,arg1,arg2  閱讀全文

     摘要: 先做個廣告，去皮兒網，可以每月26日通知你是否搖號中簽。http://www.qupier.com

一直以來，組件一直都建立在技術的層面上。由于業務的復雜多變，似乎沒有人想著把業務部分也做成可重用的組件。

我們團隊在過去的兩年里面在這個方面做了一些常識，寫出來供網友參考、拍磚。  閱讀全文

     摘要: 在以往的應用開發過程中，后端的業務組件（Action/Service/Dao），可以被設置為幾種作用域：request、session、application。我們不可能把與每次請求關系很強的一些信息（例如某個列表頁面要列出來的數據集合）簡單的放到session里面去，這就導致了每次請求之間的大部分數據是不可能共享的。使用JSF，我們實現了一種叫做view的作用域，在不同的請求之間共享信息。  閱讀全文

     摘要: JSF的很多文檔上面說，要建立一個自定義組件，需要定義繼承自UIComponentBase之類的類，然后寫decode/encode方法等等，一大套內容，很復雜。幸好我們有其他的辦法。其實定義一個組件在大多數情況下是不用去寫這樣的代碼的。本節的內容是一個選擇true/false兩個值得下拉框組件。定義一個這樣的組件需要做如下工作：  閱讀全文

     摘要: 我看到的若干mvc框架在展現一個包含動態數據內容的頁面的時候，都是這樣做的：請求/xx.do，到達某個action，執行配置好或者根據url映射到的某個方法，初始化數據，放到某個context里面（例如Request，或者struts用的ognl的context），然后根據配置或者規則，forward到某頁面，然后展現。

這樣做的好處是強制性的分離了展現和邏輯，缺點是多了若干配置，不自然。

JSF的路子和asp/php是一樣的，你請求/a.xhtml，那么，ok，加載/a.xhtml文件。例如a.xhtml主體內容如下：  閱讀全文

     摘要: 先補充一下上一篇留下的尾巴：最早看JSF的書的時候，使用jsp作為頁面，#{xx}這樣的標記不能直接寫在頁面里，必須套在一個標記里面（和struts2里面的ognl一樣郁悶）。后來才知道，這是jsp的問題，不是JSF的問題。現在大家都是用facelets作JSF的展現，JSF2.0更是把這個標準化為首選。于是直接在頁面上寫#{someAction.doSth('Hello')}，完全OK，頁面加載的時候會觸發調用該方法。

然后我們再來看后端知道前端有什么的例子：  閱讀全文

     摘要: 現在開始說JSF的優勢。一個一個的說，最后整理的時候再分主次吧，現在先就針對上面的幾個問題來說。

1.URL到action method  閱讀全文

     摘要: 首先，看看在使用struts等框架做開發的時候，遇到的一些問題.  閱讀全文

     摘要: 09年4月我從A公司離職，被同事拉到一個創業團隊做網頁游戲，他們當時使用的技術體系是基于Seam的。而我則是SSH的忠實用戶，此前一直跟隨江南白衣、appfuse的路線，大大小小也做了一些項目，也自己攢了一堆輪子。花了1年多的時間在一個基于元數據的基礎框架上面，那時候我基本上掌握了maven的簡單使用，于是自己做的一些基礎性的東西也都是使用maven來做依賴管理、版本發布。  閱讀全文

     摘要: 這總覽，很明顯是看FacesServlet的service方法。在FacesServlet的初始化過程中，構造出了全局的FacesContextFactory對象和LifeCycle對象。可以把FacesContextFactory看做是一個“請求包裝工廠”，于是很明顯，每當一個請求到達FacesServlet的時候，第一步便是拿著請求，到包裝工廠里面包裝一下，而包裝的結果就是一個FacesContext。  閱讀全文

     摘要: JSF應用中，在web.xml里面配置了一個Servlet，叫做javax.faces.webapp.FacesServlet，于是可以知道，查看、了解一個請求的處理過程可以從這里開始。從官方網站上下載JSF的源代碼，項目名比較古怪，叫做“mojarra”，我看的版本是1.2_12_b01。里面包含了兩個子項目，一個是jsf-api，里面大多是接口以及少量關鍵類。另外一個項目叫做jsf-ri，對著這個"ri"邪念了半天之后，終于在兄弟提醒之下想明白了是reference implementation的意思。jsf-api是JavaEE標準的一部分，里面的類型包名都是以javax.faces開頭的，而jsf-ri項目是sun針對JSF標準的一個參考實現，里面的類型的包名都是以com.sun.faces開頭的。  閱讀全文