積累,創造,分享!

按照hibernate3的官方中文說明文檔，進行配置運行，將文檔中提出所必須的包引用完畢，運行時卻發現報錯。錯誤如下：ClassNotFound  javax.transaction.SystemException。將jta.jar拷入后問題便解決。于是產生了一個疑惑，jta包到底是不是必須的？這個問題有待深入。

最近在項目當中負責了登錄模塊的開發，采取的方式是最常見的那種，即提交表單到業務層對數據庫中的字段進行比較。這使我有了進一步想了解JAAS的沖動，sun的tutorial還沒來得及看，E文看的比較慢，還是先google出中文得到一個大概的印象吧。
Java Authentication and Authorization Service 在 JDK 1.4 正式加入 Java 標準的 Security 模塊, 簡單來說, JAAS 就是讓我們把身份驗證與權限管控使用標準的方法來開發。根據google到的信息得知。
JAAS主要的類如下：
普通對象

• Subject
• Principals
• Credentials

身份驗證相關的對象

• LoginContext
• LoginModule
• CallbackHandler
• Callback

權限管控相關的對象

• Policy
• AuthPermission
• PrivateCredentialPermission

接下來便是利用空余時間通過JDK，tutorial進行研究了。希望不是半途而廢，也謹以此文記下，以表決心。

前段時間瞎逛Jdon和Javaeye，2個都是名氣非常大的Java社區。上面不乏許多國內IT界的名人，大牛。
仔細看了他們的帖子，發現這兩個社區之間的爭斗也是非常有意思的。爭斗的源頭是EJB與Hibernate。
兩派人士論經據典，擺資論闊。最后都已經針對上個人了，雙方都是些人物。誰是誰非暫且就不在這里評論了，但這讓我突然想起了一句話，“做技術的一定要學會寬容。”這是位業內的前輩告誡我的，是的，一項新技術的出現，必然有他的道理，不要貿然去評判它，你所做的，是先弄清它，然后再吸取它的經驗，好的地方可以借鑒，不好的地方，盡量去避免。刻薄的評論，只會顯得自己的幼稚與淺薄。而這些錯誤，是我們經常犯的。
做人的道理尚且如此，做技術的呢？

對于一種不夠完美的技術，批評它總是容易的；若是拿不出更有建設性的方案，那批評也只能叫廉價的批評。
“雖然是做程序員，但是不能只把自己 當成程序員。你還可以為你的老板和公司著想。但并不是找到問題就萬事大吉，任何公司從來不缺挑刺兒的人。因為你看到的問題，可能不曉得有多少人早抱怨過 了！所以你與其就這么跑去找老板而于事無補，還不如調查研究后，帶著解決方案去找老板，這才是上策。只有一個指出了核心問題又拿出了有效解決方案的員工， 才會得到老板的重視和信任。【唐駿語】

在和銀行的合作中，我們遇到不少困難。但正因為有困難，整件事情才更有操作的價值和意義。如果這個東西三天就做好了，那么我肯定對這個事情沒有興趣。 【馬云語】
題外音：
對于技術問題，太簡單說明沒有技術含量。
對于商業問題，太簡單就容易模仿沒有核心競爭力。

我做這個公司賣什么？不買產品，也不買公司，我賣的是我自己。你只要讓別人覺得你值得信任，那么什么產品都賣得出去。【tr老板語】

權限控制是每個項目必不可少的一塊。在最近的一個MVC模式(Struts)的實踐當中，在進行權限訪問控制時做了一個這樣的嘗試，即在action當中進行權限控制，它所控制的粒度可以到用戶的每個操作上，比如說增刪改查，當然，我這里所說的權限是控制到功能級的，系統還沒有復雜到對實例級別的控制。
具體的例子如下：先定義一個BaseDispatchAction，此類繼承Struts當中的DispatchAction，其中有個權限檢查的方法  

funcId指的是當前的欄目，operationId為當前欄目的功能操作ID，將功能ID與操作ID在checkPermit方法當中與當前用戶所在的角色資源進行判斷，看是否符合當前操作。
比如具體到一個新增操作，可以在相對應的功能操作表中定義對應的操作ID。在接下來的具體某個action當中，先繼承BaseDispatchAction，比如用戶管理模塊的UserManangeAction。然后在新增方法當中加入如下代碼控制，   

這樣，對具體的某個功能操作就進行了很好的控制。