jalor5是一套功能強大的框架，該框架集成了spring、mybatis、cxf、日志、異常等組件，和其它未提及的部分組件，如消息組件。
它還自帶了權限管理，內容管理，國際化等功能，該框架在項目開發中起到了縮短項目周期和降低技術難度的功能。
雖然jalor5的開發和使用都有大量文檔，但是我覺得一個從未接觸過jalor5甚至未接觸過Spring框架的人來說，單單靠jalor5的文檔，
還是會遇到很多的問題，比如環境搭建，數據流的方向等。jalor5是在jdk1.5的環境下開發的，文檔中說使用其它的jdk版本或許會存在問題，
但是如果用jdk1.5的話jalor5會有錯誤，而且在新建項目中也存在一些細節與文檔上的差別，文檔中的部分例子不夠全面，使得在學習過程中
遇到了很多小的但是又難以解決的問題。就算環境搭建都沒問題了，在建好項目了之后也會遇到個別的問題，比如數據庫的初始化、包名的固定
命名、請求url的寫法，各個應用層代表的意思，接口層中path注解的命名都會遇到各種不同的問題。下面我說說我遇到的問題和解決方法：
問題（僅是我遇到的，大家使用的時候不一定會遇到）：
1、lib包的編譯問題，剛開始的時候提示編譯版本不對，要使用jdk1.5版本編譯。解決方法：按照提示改成jdk1.5編譯即可（改了之
后再切換回jdk1.6錯誤不提示了，很是奇怪）。
2、數據庫初始化問題。jalor5的使用必須初始化數據庫，而oracle的安裝和導入數據腳本是必要的，但是導入腳本過程中也要注意
修改腳本中的appname和scope的名字，我是只改了appname為自己的應用程序名即可。因為jalor5的后台管理菜單的內容是
根據appname去獲取的，所以這一步是必須的。
3、新建項目中包的命名，我自己隨便命名，結果程序一直報錯。解決方法很簡單，修改包名為com.huawei.it打頭即可，當然相應的
層命名必須包含有dao、service等全小寫的單詞，因為spring配置是要去掃描這些配置的路徑的。
比如service的包命名：com.huawei.it.yq.report.service 其中yq是應用程序名、report是模塊名、service代表服務層。
4、api接口層、impl實現層、test測試層、test測試支持層（test.support）、web層的概念：
api接口層：在這一層中全部放置接口類，接口類包括dao數據庫打交道層的接口、service服務邏輯層的接口；還放數據庫表
對應的java類對象，即vo對象。該層的service接口需配置@Path注解和@Produces注解。
impl實現層：依賴api層，在這一層中全部放置api層接口的實現類和dao接口對應的映射xml文件（mybatis文件）。在service實現類中必須
使用@Named注解。在service實現類中用到dao接口要使用@Inject注解。
test測試層：依賴impl層、test測試支持層，使用junit4來編寫測試類，測試service實現類是否可用可行。這樣子不用每次都啟動tomcat來測試。
test測試支持層：該層只存放兩個配置文件：xx.test.support.beans.xml、xx.test.support.configs.xml，需修改數據庫連接代碼等。
web層：該層最重要的就是web.xml配置文件和application.xml文件，還有config文件下的幾個配置文件。該層沒有何人其它文件，
它的存在只是為了加載我們的應用程序api和應用程序impl，tomcat啟動的時候就會把api、impl層編譯裝載，它們就全部在一個web里面了。
5、分頁傳遞參數最好以對象的形式去傳遞參數。
6、vo、dao、dao的映射xml文件的自動生成，在路徑中選擇api層中的src/main/java路徑，包名必須以com.huawei.it打頭。
7、html頁面、js文件的代碼編寫。css文件的引用。
8、國際化信息管理，當添加國際化信息后，需要清空緩存才能顯示，這點要注意。
而我在這兩周的時間學習了jalor5的一些功能，主要是我們當前項目需要用到的，主要知識點有：
1、IGrid表格的數據顯示，數據來自oracle數據庫。
2、IGrid中實現數據的批量添加、修改、刪除。
3、IGrid實現過濾功能，有降序、升序，過濾條件有等於、大於、包含等，單選按鈕、多選框選擇過濾等。
4、from表單的數據顯示、修改、增加記錄的實現。
5、表單主要用到文本框控件、單選按鈕多選按鈕控件、時間控件、下拉選擇控件等。
對jalor的數據流方向有了一定的了解，知道模塊開發的流程、功能的開發流程，從項目的搭建、數據庫的連接、前后台的數據交互都有了一定的了解，我知道jalor5的很多
知識都還需要學習，但是我覺得不需要全部都精通jalor5再去做項目，沒有必要。其它的知識點可以在需要的時候再去學習，這樣可以一邊做項目一邊熟悉，再不懂的可以請求jalor5
Jalor3 中沿用的古老的七層Pattern架構，產生了大量吃閑飯的冗余代碼，想必很多人都深有體會，恨之入骨。我們可不敢站在人民的對立面，於是我們決定精簡代碼層次，推出Jalor5框架，來解決大家的心頭之恨。正如大家知道的，Jalor5 最終采用 展現層/服務層/數據訪問層/數據庫層的精簡4層結構，不過這個四層架構的來歷也並不簡單。剛開始的時候，我們團隊內部對新的架構存在一些分歧，部分團隊成員堅持認為應該在展現層和服務層中間增加服務Facade層，理由是便於在這一層上進行權限控制和服務暴露，如果沒有這一層，由於服務層之間的相互調用，權限將在一個網狀結構中傳遞，眾所周知，網狀結構是難於控制的。
舉個簡單的例子：A服務，調用了B服務和C服務來進行一個完整的操作，在沒有服務Facade層的情況下：
1. 如果ABC三個服務都控制了權限，難道我們要給用戶授予ABC三個權限，用戶才能使用A服務？這顯然是不可接受的
2. 那我們換個方式：利用技術手段，只在A上控制權限，忽略BC的權限控制，有時候B操作是個關鍵操作，必須強制進行權限校驗，也是不可接受的
3. 如果A是個批量保存的操作，他調用批量更新的操作B和批量新增的服務C來完成任務，這時A不控制權限，而交由B和C分開控制，對於沒有新增權限的人，如果提交的數據中只有更新數據的，這個操作仍然可以成功。
4. 更復雜的情況，A服務是不控制權限的，B服務又調用了D服務，C服務又調用了E服務，或者交叉起來
顯然問題的復雜性在一步一步上升。
我們來做個比喻，你去一個大的景點玩（A服務），買了張門票，到里面的大部分景點（B、C）是不需要再買新的門票的，但是有一些特殊景點可能需要。有的大景點是免費的，里面的小景點（B、C）要分開買票。更復雜的情況是，大景點（A）是免費的，里面有兩個收費的中型景點（B、C），中型景點里面又有小景點（D、E），這些小景點只認對應的中型景點的門票（D只認B門票，E只認C門票）。
增加一個服務Facade層可以有效的解決這個權限的問題，權限僅在Facade層控制，也就不存在網狀問題了。但是為了這少部分的權限場景，增加這一層吃閑飯的到底划不划算？我們可不敢再一次站在人民的對立面。
我們徘徊在大中小景點門前，思緒如那團網狀的亂麻，我們真的要接受這個一刀切的超級聯票嗎?我們真的要放棄心底對極致簡約的追求嗎?
如果你看了標題，你就知道上面兩個問題的答案是否定的。
有的時候我們走入了困境，總希望遇到可以指點迷津的大師。我時常夢見，大師拄着禪杖，道一聲哦米拖佛，說施主你只需如此這般(此次省略411個字)便可。
其實，無論你指望，或者不指望，大師就在那里，也不曾走遠，只是你看不見，也摸不着。EJB 的設計者中就有這樣的大師。我們回想起 EJB 中的事務傳播模型，發現 EJB 的事務就是在一個類似的網狀結構中傳播。
參考前輩的方案，我們將每個服務對權限的控制策略分成了幾種：Mandatory（強制校驗）、Required（前面校驗了我就不校驗，否則校驗）、IgnoreAll（忽略后繼所有的權限校驗） 等幾個級別，並引入了棧、楨來管理傳播關系，權限攔截器根據服務的權限控制策略來進行必要的控制，這個問題也就迎刃而解了。
以上述例4來說，其偽代碼如下：
java代碼
public void a(...){
...
b();
c();
...
}
@JalorOperation(policy=Required,code="..",desc="..")
public void b(...){
d();
...
}
@JalorOperation(policy=Required,code="..",desc="..")
public void c(...){
e();
...
}
@JalorOperation(policy=Required,code="..",desc="..")
public void d(